Re: [PATCH 68/88] arm: Rename STM32MP13x
Hi, On 1/23/23 23:00, Simon Glass wrote: CONFIG options must not use lower-case letter. Convert this and related ones to upper case. Signed-off-by: Simon Glass --- arch/arm/dts/Makefile | 2 +- arch/arm/mach-stm32mp/Kconfig | 4 ++-- arch/arm/mach-stm32mp/Kconfig.13x | 4 ++-- arch/arm/mach-stm32mp/Makefile | 2 +- arch/arm/mach-stm32mp/cmd_stm32key.c | 10 +- arch/arm/mach-stm32mp/fdt.c| 4 ++-- arch/arm/mach-stm32mp/include/mach/stm32.h | 6 +++--- board/st/common/Kconfig| 2 +- board/st/stm32mp1/Kconfig | 2 +- configs/stm32mp13_defconfig| 4 ++-- drivers/clk/stm32/Kconfig | 2 +- 11 files changed, 21 insertions(+), 21 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 69/88] arm: Rename STM32MP15x
Hi, On 1/23/23 23:00, Simon Glass wrote: CONFIG options must not use lower-case letter. Convert this and related ones to upper case. Signed-off-by: Simon Glass --- arch/arm/dts/Makefile | 2 +- arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 ++-- arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4 ++-- arch/arm/mach-stm32mp/Kconfig | 6 +++--- arch/arm/mach-stm32mp/Kconfig.15x | 6 +++--- arch/arm/mach-stm32mp/Makefile | 2 +- arch/arm/mach-stm32mp/cmd_stm32key.c | 10 +- .../mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +- .../arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 4 ++-- .../arm/mach-stm32mp/cmd_stm32prog/stm32prog.h | 6 +++--- arch/arm/mach-stm32mp/fdt.c| 8 arch/arm/mach-stm32mp/include/mach/stm32.h | 10 +- arch/arm/mach-stm32mp/include/mach/stm32prog.h | 2 +- board/st/common/Kconfig| 14 +++--- board/st/common/stm32mp_mtdparts.c | 18 +- board/st/stm32mp1/Kconfig | 2 +- board/st/stm32mp1/stm32mp1.c | 6 +++--- configs/stm32mp15_basic_defconfig | 2 +- configs/stm32mp15_defconfig| 2 +- configs/stm32mp15_trusted_defconfig| 4 ++-- drivers/clk/stm32/Kconfig | 2 +- 22 files changed, 59 insertions(+), 59 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 47/88] mtd: Drop unused fsmc_nand driver
Hi, On 1/23/23 22:59, Simon Glass wrote: This is not used since this commit: 570c3dcfc15 arm: Remove spear600 boards and the rest of SPEAr support Drop the driver and Kconfig option. Signed-off-by: Simon Glass --- drivers/mtd/nand/raw/Makefile| 1 - drivers/mtd/nand/raw/fsmc_nand.c | 470 --- include/linux/mtd/fsmc_nand.h| 84 -- 3 files changed, 555 deletions(-) delete mode 100644 drivers/mtd/nand/raw/fsmc_nand.c delete mode 100644 include/linux/mtd/fsmc_nand.h For STMicroelectronics / SPEAr Reviewed-by: Patrick Delaunay Thanks Patrick
[PATCH 2/2] mmc: remove SDHCI SPEAR
As the file spear_sdhci.c file is already removed, delete the associated
configuration CONFIG_MMC_SDHCI_SPEAR.
Fixes: c942fc925e7dab ("mmc: spear: remove the entire spear_sdhci.c file")
Signed-off-by: Patrick Delaunay
---
drivers/mmc/Kconfig | 12
drivers/mmc/Makefile | 1 -
2 files changed, 13 deletions(-)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 878f867c627b..80641e139305 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -667,18 +667,6 @@ config MMC_SDHCI_S5P
If unsure, say N.
-config MMC_SDHCI_SPEAR
- bool "SDHCI support on ST SPEAr platform"
- depends on MMC_SDHCI
- help
- This selects the Secure Digital Host Controller Interface (SDHCI)
- often referrered to as the HSMMC block in some of the ST SPEAR range
- of SoC
-
- If you have a controller with this interface, say Y here.
-
- If unsure, say N.
-
config MMC_SDHCI_STI
bool "SDHCI support for STMicroelectronics SoC"
depends on MMC_SDHCI && OF_CONTROL
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 3dc757108d5a..2c65c4765ab2 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -70,7 +70,6 @@ obj-$(CONFIG_MMC_SDHCI_NPCM)+= npcm_sdhci.o
obj-$(CONFIG_MMC_SDHCI_PIC32) += pic32_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ROCKCHIP) += rockchip_sdhci.o
obj-$(CONFIG_MMC_SDHCI_S5P)+= s5p_sdhci.o
-obj-$(CONFIG_MMC_SDHCI_SPEAR) += spear_sdhci.o
obj-$(CONFIG_MMC_SDHCI_STI)+= sti_sdhci.o
obj-$(CONFIG_MMC_SDHCI_TANGIER)+= tangier_sdhci.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += tegra_mmc.o
--
2.25.1
[PATCH 1/2] ARM: remove SPEAR entry in makefile
As the lastest spear directories are removed, delete the associated entry
in Makefile.
Fixes: 570c3dcfc153 ("arm: Remove spear600 boards and the rest of SPEAr
support")
Signed-off-by: Patrick Delaunay
---
arch/arm/cpu/arm926ejs/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index 7e7ad4f35d7e..8cfe3f0fbbc2 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -13,7 +13,6 @@ endif
endif
obj-$(if $(filter mxs,$(SOC)),y) += mxs/
-obj-$(if $(filter spear,$(SOC)),y) += spear/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
# some files can only build in ARM or THUMB2, not THUMB1
--
2.25.1
Re: [PATCH] fastboot: Only call the bootm command if it is enabled
Hi,
On 2/20/23 07:14, Samuel Holland wrote:
This fixes an error with trying to link against do_bootm() when
CONFIG_CMD_BOOTM is disabled.
Signed-off-by: Samuel Holland
---
drivers/fastboot/fb_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 57b6182c46a..20aa80838ae 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -135,7 +135,7 @@ void fastboot_boot(void)
s = env_get("fastboot_bootcmd");
if (s) {
run_command(s, CMD_FLAG_ENV);
- } else {
+ } else if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
static char boot_addr_start[20];
static char *const bootm_args[] = {
"bootm", boot_addr_start, NULL
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
Hi,
On 2/17/23 10:28, Michal Suchánek wrote:
Hello,
On Sun, Feb 12, 2023 at 06:45:36PM -0500, Tom Rini wrote:
On Wed, Feb 08, 2023 at 02:50:16PM -0500, Tom Rini wrote:
On Wed, Feb 08, 2023 at 08:11:34PM +0100, Michal Suchánek wrote:
Hello,
On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
Hello,
On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
It is reported that in some configurations it is not possible to boot
because u-boot runs out of lmbs.
commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
hence is likely the cause of the lmb overflow.
Fixes: 06d514d77c ("lmb: consider EFI memory map")
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
Signed-off-by: Michal Suchanek
Reviewed-by: Francesco Dolcini
I plan to pick up
https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
as the alternative fix for this issue and would suggest that any distro
hitting the problem on v2023.01 apply the above instead of increasing
the limit.
Tom, my understanding is that you plan to merge this or an equivalent
change, correct? Otherwise I would need to send some more patches to
update a few board defconfig that are affected by this specific issue.
Yes, I was hoping to push the equivalent of this patch a few hours ago,
along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
scale past 8, and I just now figured out what that should look like
instead, I believe.
reportedly neither fixes the problem in all cases, and raising
CONFIG_LMB_RESERVED_REGIONS is required.
Looks like the mechanism to add regions above the default number does
not work as intended.
The test is to boot rPi 4 from USB directly with recent firmware.
Well, given 0089affee275 ("configs: stm32mp15: increase the number of
reserved memory region in lmb") I guess this has been run in to before,
but not resolved more generically.
I wonder if
https://patchwork.ozlabs.org/project/uboot/patch/20230212150706.2967007-2-sjo...@collabora.com/
is what will finish dealing with these issues, even the ones that had
perhaps shown up before and been addressed in the commit I mentioned
above?
Looks like this together with raising the maximum number of regions
works, that is v2023.04-rc2 should be fixed.
Thanks
Michal
For STM32MP15x platform with have the same issue when the number of
reserved regions increased in Linux device tree.
I try to increase the region by default with CONFIG_LMB_MAX_REGIONS,
but my patch increase the used RAM size for some platform (with
compilation issue).
For Tom ask me to propose a backward compatible configuration
https://lore.kernel.org/all/18550712-c32d-e08b-c38e-6c63bad09...@foss.st.com/
=> CONFIG_USE_LMB_MAX_REGIONS
Moreover, if you increased CONFIG_LMB_MAX_REGIONS
the same number of region (N) is used for reserved regions (N) and for
memory region (N)
=> the total size used = 2 * N * size of each memory region descriptor.
But for most of case only the number reserved regions need to be
increased to parse the device tree.
With my patch the number of regions are statically managed by 2 array
independently
- reserved regions = CONFIG_LMB_RESERVED_REGIONS
- memory region = CONFIG_LMB_MEMORY_REGIONS
And the total number of region (size of struct in memory) =
CONFIG_LMB_RESERVED_REGIONS + CONFIG_LMB_MEMORY_REGIONS
I think a good solution to have by default, if you want managed more
reserved memory by default in U-Boot for all platform:
=> LMB_USE_MAX_REGIONS=n instead of 'y' today
=> LMB_MEMORY_REGIONS=8
=> LMB_RESERVED_REGIONS=16 or 32 instead of 8 today by default
And change the defconfig for the size constraint platforms
to use the previous behavior with LMB_USE_MAX_REGIONS=y.
NB: I define the default value with 8 to keep the previous limit and
I just increase the number of region for the STM32MP platform:
configs/stm32mp15_defconfig:170:CONFIG_LMB_RESERVED_REGIONS=16
configs/stm32mp15_trusted_defconfig:170:CONFIG_LMB_RESERVED_REGIONS=16
configs/stm32mp13_defconfig:81:CONFIG_LMB_RESERVED_REGIONS=16
configs/stm32mp15_basic_defconfig:194:CONFIG_LMB_RESERVED_REGIONS=16
I use the default value for CONFIG_LMB_MEMORY_REGIONS =8
Reference =
https://lore.kernel.org/all/20210310091632.17103-1-patrick.delau...@foss.st.com/
Patrick
Re: [PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS
On 2/8/23 16:16, Tom Rini wrote: On Wed, Feb 08, 2023 at 03:13:31PM +, Philippe Schenker wrote: On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: On Wed, Feb 08, 2023 at 02:33:58PM +, Philippe Schenker wrote: Hi Tom, We currently face an issue on our apalis-imx8 machine, that is not able to boot with a ramdisk. What happens is that there are all 8 of 8 LMBs reserved and fdt tries to allocate one more, probably for relocation. I now stumbled on this recent patch and noticed that in my understanding this is introducing a regression to all the boards you remove `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? For the other question this raises to me is it in general safe to just increase this limit, let's say to 16? And since it was quite an effort debugging this issue I thought of adding a debug print if the MAX cnt in lmb.c is being hit to ease that pain for other devs, would you be fine with something like this? Right, so with the late in the cycle change to make EFI use LMBs as well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The change here switches from a static allocation of a maximum number of LMBs to dynamically allocating as many of them as needed. But since you no longer enable LMB_USE_MAX_REGIONS then theres the two limits (default=8) LMB_MEMORY_REGIONS=8 LMB_RESERVED_REGIONS=8 that are limiting the maximum LMB numbers. So in my view this commit does create a regression for all boards you delete `CONFIG_LMB_MAX_REGIONS=64`. At least for me rgn->max is still set to 8 and also after this commit I hit that limit. [1] [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288 Ugh, you're right and I missed what this ended up doing, thanks for explaining it. I'll go revert my commit shortly and pick up one of the ones that raised the default. Hi, only for reference, with new LMB management config LMB_USE_MAX_REGIONS bool "Use a common number of memory and reserved regions in lmb lib" depends on LMB - default y The correct patch without regression is for each board -CONFIG_LMB_MAX_REGIONS=64 +CONFIG_LMB_RESERVED_REGIONS=64 See https://lore.kernel.org/all/20210310091632.17103-1-patrick.delau...@foss.st.com/ Patrick
Re: [PATCH v2 2/2] usb: move CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to USB
Hi,
On 1/25/23 19:40, Heinrich Schuchardt wrote:
This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.
The setting is only relevant in USB host mode.
Fixes: 5454dea3137d ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt
---
v2:
let CONFIG_USB_HUB_DEBOUNCE_TIMEOUT depend on CONFIG_USB_HOST
---
common/Kconfig | 12
drivers/usb/Kconfig | 11 +++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index e3a5e1be1e..0afc01b759 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1106,15 +1106,3 @@ config FDT_SIMPLEFB
config IO_TRACE
bool
-
-config USB_HUB_DEBOUNCE_TIMEOUT
- int "Timeout in milliseconds for USB HUB connection"
- depends on USB
- default 1000
- help
- Value in milliseconds of the USB connection timeout, the max delay to
- wait the hub port status to be connected steadily after being powered
- off and powered on in the usb hub driver.
- This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
- value = 1s because some usb device needs around 1.5s to be initialized
- and a 2s value should solve detection issue on problematic USB keys.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ebe6bf9498..94fb32d107 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -115,6 +115,17 @@ config USB_ONBOARD_HUB
power regulator. An example for such a hub is the Microchip
USB2514B.
+config USB_HUB_DEBOUNCE_TIMEOUT
+ int "Timeout in milliseconds for USB HUB connection"
+ default 1000
+ help
+ Value in milliseconds of the USB connection timeout, the max delay to
+ wait the hub port status to be connected steadily after being powered
+ off and powered on in the usb hub driver.
+ This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+ value = 1s because some usb device needs around 1.5s to be initialized
+ and a 2s value should solve detection issue on problematic USB keys.
+
if USB_KEYBOARD
config USB_KEYBOARD_FN_KEYS
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH v1 0/3] fdt: Fix mtparts fixup
Hi, On 1/23/23 21:01, Tom Rini wrote: On Mon, Jan 23, 2023 at 11:06:06AM +0100, Miquel Raynal wrote: Hi Tom, tr...@konsulko.com wrote on Fri, 13 Jan 2023 14:34:11 -0500: On Fri, Jan 13, 2023 at 07:45:44PM +0100, Francesco Dolcini wrote: From: Francesco Dolcini Recently we had a boot regression on colibri-imx7 because of a cleanup change on Linux imx7.dtsi setting nand controller node #size-cells from 1 to 0. Because of that Linux partition parser was no longer able to properly parse the OF partitions leading to a boot failure, the above change was reverted in the meantime as an immediate workaround, but some improvement is required on both Linux and U-Boot. This change improve the U-Boot part of it, #size-cell is set to 1 when it has an invalid value. This has the limitation to work only with devices smaller than 4GiB. In general the suggestion from the Linux MTD maintainer would be to just deprecate using this U-Boot function and pass the MTD partitions from the command line, unless they are statically defined in the DTS file in the first place. This series therefore convert colibri-imx6ull and colibri-imx7 to pass the partition list from the command line instead of fixing up the DT. Link: https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/ Link: https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/ My higher level question / concern here is, is using one of the dts partition schemes still valid / preferred, or should everyone now have reverted to passing via the kernel command line? If device tree still, is mtd/partitions/fixed-partitions.yaml the one to follow or something else? I don't think we can "prefer" one mode over the other between cmdline and DTS. Both should work pretty well. Of course on the cmdline you can only define fixed partitions and many devices require more advanced parsers, which are only available through DTS, but for simple partitions, it works totally okay. When both are present, which one is used? The only thing that I would like to avoid is the need to write code in the bootloaders to tweak the FDT in order to add partitions. That is clearly not needed, error prone, and do not follow evolution of the "standard", as we just discovered. I'm not sure about this. Looking around in U-Boot today, I see two types of cases. One of which, the colibri case, can clearly be not done and either passed on the command line, or put in to the device tree as there's nothing run-time related being tweaked here. That's a fine path to take on those platforms and Francesco's patches should be updated to remove the unused C code too from the board code. But the other cases are doing something dynamic and run-time related. There's the omap3 igep00x0 family (which yes, legacy) that is doing NAND or oneNAND and adjusting things at run time. I don't know how much anyone has interest in those platforms at this point, nor exactly who to contact (for Linux or U-Boot). There's also the stm32mp1 family doing something that's very not obvious at first glance, so I've cc'd the maintainers there. For information, today for stm32mp1 family we are using the build of MTDPARTS and fdt fixup, only for backward compatibility issue (the MTD partitions change for boot with or without OP-TEE, with or wihtout FIP, with SPL). Today we are already plan to remove this dynamic management and to switch to static MTD partition defined in device tree, as already proposed by Tom in the serie "mtd: spi: nor: force mtd name to "nor%d"" http://patchwork.ozlabs.org/project/uboot/patch/20210916155040.v3.2.Ia461e670c7438478aa8f8939209d45c818ccd284@changeid/ This patchset is already ready, we are currently testing it internally and it should be pushed when it will be validated in our donwstream. Regards Patrick
Re: [PATCH v2 1/2] env: mmc: Clean up macro usage
Hi Marek,
On 2/9/23 13:30, Marek Vasut wrote:
Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of
mix of ifdef.
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
V2: Replace CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) with
IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)
---
env/mmc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/env/mmc.c b/env/mmc.c
index 5b01f657a7a..d51a5579128 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
if (str && !strncmp((const char *)info.name, str, sizeof(info.name)))
break;
-#ifdef CONFIG_PARTITION_TYPE_GUID
- if (!str) {
+ if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && !str) {
const efi_guid_t env_guid =
PARTITION_U_BOOT_ENVIRONMENT;
efi_guid_t type_guid;
@@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str, int copy, s64 *val)
if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
break;
}
-#endif
}
/* round up to info.blksz */
If I remenber, I try this test with IS_ENABLED when I propose my patch
and I have compilation issue on next line
+ uuid_str_to_bin(info.type_guid, type_guid.b,
UUID_STR_FORMAT_GUID);
because "info.type_guid" don't exist in struct disk_partition
see ./include/part.h:59
struct disk_partition {
lbaint_t start; /* # of first block in partition */
...
#ifdef CONFIG_PARTITION_TYPE_GUID
char type_guid[UUID_STR_LEN + 1]; /* type GUID as string, if
exists */
#endif
...
};
Regards
Patrick
[PATCH] fs: ext4: check the minimal partition size to mount
No need to mount a too small partition to handle a EXT4 file system.
This patch add a test on partition size before to read the
SUPERBLOCK_SIZE buffer and avoid error latter in fs_devread() function.
Signed-off-by: Patrick Delaunay
---
This patch avoids traces when EFI try to detect FS type on one GPT
partition with only one LBA (512 octetcs):
fs_devread read outside partition 2
Failed to mount ext2 filesystem..
FyleSytem type is searched by efi_disk_create_part() / efi_fs_exists()
Even if these traces are removed by commit f337fb9ea8b8 ("fs: Quieten down
the filesystems more"), if think it should be good to avoid to read
outside partition at the start of this function by a simple test.
fs/ext4/ext4_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index f50de7c089e6..9a9c520e22ca 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2373,6 +2373,10 @@ int ext4fs_mount(unsigned part_length)
struct ext2_data *data;
int status;
struct ext_filesystem *fs = get_fs();
+
+ if (part_length < SUPERBLOCK_SIZE)
+ return 0;
+
data = zalloc(SUPERBLOCK_SIZE);
if (!data)
return 0;
--
2.25.1
[PATCH 1/2] efi: remove error in efi_disk_probe
EFI has no reason to block the dm core device_probe() in the callback
efi_disk_probe() registered with EVT_DM_POST_PROBE.
This patch avoids to have error in DM core on device_probe()
ret = device_notify(dev, EVT_DM_POST_PROBE);
only because EFI is not able to create its instance/handle.
For example on usb start, when the SAME KEY (PID/VID) is present on
2 ports of the USB HUB, the 2nd key have the same EFI device path
with the call stack:
efi_disk_probe()
efi_disk_create_raw()
efi_disk_add_dev()
efi_install_multiple_protocol_interfaces()
EFI_ALREADY_STARTED
In case of error in probe, the 2nd key is unbound and deactivated for
the next usb commands even if the limitation is only for EFI.
This patch removes any return error in probe event callback;
if something occurs in EFI registration, the device is still probed.
Signed-off-by: Patrick Delaunay
---
lib/efi_loader/efi_disk.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8e7..8d53ba3bd27e 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -677,14 +677,18 @@ int efi_disk_probe(void *ctx, struct event *event)
desc = dev_get_uclass_plat(dev);
if (desc->uclass_id != UCLASS_EFI_LOADER) {
ret = efi_disk_create_raw(dev, agent_handle);
- if (ret)
- return -1;
+ if (ret) {
+ log_err("efi_disk_create_raw %s failed (%d)\n",
+ dev->name, ret);
+ return 0;
+ }
}
device_foreach_child(child, dev) {
ret = efi_disk_create_part(child, agent_handle);
if (ret)
- return -1;
+ log_err("efi_disk_create_part %s failed (%d)\n",
+ dev->name, ret);
}
return 0;
--
2.25.1
[PATCH 0/2] efi: remove error in efi_disk_probe/efi_disk_remove
Proposed serie after investigate crash:
- board stm32mp157c-dk2, including a USB HUB 4 ports
- 2 USB key on the USB HUB (same PID/VID)
- multiple command usb start/usb stop
Without these patches, U-Boot failed to probe / failed to unbind the 2nd
key and crash in USB stack, usb_find_usb2_hub_address_port()
When the probe for USB child failed, the unbind failed also.
For example when PSCI stack can't handle 2 devices with the same EFI
handle based on PIDVID for USB device.
On the "usb stop" command, the USB tree becomes invalid as the EFI
stack forbids to remove the USB devices, the USB are still present
(checked with "dm tree" command).
On the next USB start, on USB scan, when the USB devices children of
USB HUB are added dynamically, the USB stack crashes...
I propose to remove the return error in efi_disk_probe/efi_disk_remove
and to replace them by log_error
=> even if EFI can't export the devices, the device should be
available for U-Boot proper and the probe should be complete properly
(the 2nd USB keys are see in dm tree in the example)
Sequence to reproduce the issue with 2 identical USB key
STM32MP> usb start && usb tree && usb stop && usb start && usb tree
&& usb stop && usb start && usb tree && usb stop
starting USB...
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices...
Adding disk for usb_mass_storage.lun0 failed (err=-2147483628/0x8014)
device 'usb_mass_storage.lun0' failed to unbind
3 USB Device(s) found
device 'usb_mass_storage.lun0' failed to unbind
scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 2mA)
|
+-3 Mass Storage (480 Mb/s, 200mA)
|Generic Mass Storage 81ED9AA7
|
stopping USB..
device 'usb_mass_storage.lun0' failed to unbind
device 'usb_mass_storage' failed to unbind
device 'usb_hub' failed to unbind
starting USB...
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices...
Adding disk for usb_mass_storage.lun0 failed (err=-2147483628/0x8014)
device 'usb_mass_storage.lun0' failed to unbind
3 USB Device(s) found
device 'usb_mass_storage.lun0' failed to unbind
scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 2mA)
|
+-3 Mass Storage (480 Mb/s, 200mA)
|Generic Mass Storage 81ED9AA7
|
stopping USB..
starting USB...
Bus usb@5800d000: scanning bus usb@5800d000 for devices... data abort
pc : [] lr : []
reloc pc : []lr : []
sp : dbafa708 ip : dbb54cc0 fp : dbafa780
r10: dbafac40 r9 : dbb19e80 r8 :
r7 : dbafa727 r6 : dbafa726 r5 : dbb40fc0 r4 : dbafac40
r3 : 0001 r2 : dbafa726 r1 : dbafa727 r0 :
Flags: nZCv IRQs off FIQs off Mode SVC_32 (T)
Code: 592c 4628 f008 ff1d (6843) 2b03
Resetting CPU ...
After the 2 patches, with the 2 SAME keys on the USB HUB
the EFI handle is not created, with error in trace,
BUT the USB key is available in U-Boot proper.
STM32MP> usb start && usb tree && usb stop
starting USB...
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices...
Adding disk for usb_mass_storage.lun0 failed (err=-2147483628/0x8014)
efi_disk_create_raw usb_mass_storage.lun0 failed (-2)
4 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 2mA)
|
+-3 Mass Storage (480 Mb/s, 200mA)
|Generic Mass Storage 81ED9AA7
|
+-4 Mass Storage (480 Mb/s, 200mA)
Generic Mass Storage C3EAEAD2
stopping USB..
efi_disk_remove failed for usb_mass_storage.lun0 uclass 22 (-1)
efi_disk_remove failed for usb_mass_storage.lun0:1 uclass 73 (-1)
Patrick Delaunay (2):
efi: remove error in efi_disk_probe
efi: remove error in efi_disk_remove
lib/efi_loader/efi_disk.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
--
2.25.1
[PATCH 2/2] efi: remove error in efi_disk_remove
EFI has no reason to block the driver remove when the associated EFI
resources failed to be released.
This patch avoids DM issue when an EFI resource can't be released,
for example if this resource wasn't created, for duplicated device name
(error EFI_ALREADY_STARTED).
Without this patch, the U-Boot device tree is not updated for "usb stop"
command because EFI stack can't free a resource; in usb_stop(), the
remove operation is stopped on first device_remove() error, including a
device_notify() error on any child.
And this remove error, returned by usb_stop(), is not managed in cmd/usb.c
and the next "usb start" command cause a crash because all the USB devices
need to be released before the next USB scan.
Signed-off-by: Patrick Delaunay
---
lib/efi_loader/efi_disk.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 8d53ba3bd27e..22a0035dcde2 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -767,16 +767,20 @@ int efi_disk_remove(void *ctx, struct event *event)
{
enum uclass_id id;
struct udevice *dev;
+ int ret = 0;
dev = event->data.dm.dev;
id = device_get_uclass_id(dev);
if (id == UCLASS_BLK)
- return efi_disk_delete_raw(dev);
+ ret = efi_disk_delete_raw(dev);
else if (id == UCLASS_PARTITION)
- return efi_disk_delete_part(dev);
- else
- return 0;
+ ret = efi_disk_delete_part(dev);
+
+ if (ret)
+ log_err("%s failed for %s uclass %u (%d)\n", __func__,
dev->name, id, ret);
+
+ return 0;
}
/**
--
2.25.1
Re: [PATCH 1/2] efi: remove error in efi_disk_probe
Hi,
On 3/9/23 09:57, Heinrich Schuchardt wrote:
On 3/8/23 14:26, Patrick Delaunay wrote:
EFI has no reason to block the dm core device_probe() in the callback
efi_disk_probe() registered with EVT_DM_POST_PROBE.
This patch avoids to have error in DM core on device_probe()
ret = device_notify(dev, EVT_DM_POST_PROBE);
only because EFI is not able to create its instance/handle.
This should only occur if we are out of memory or if you call
efi_disk_probe() twice for the same device.
OK
For example on usb start, when the SAME KEY (PID/VID) is present on
2 ports of the USB HUB, the 2nd key have the same EFI device path
with the call stack:
We need the HUB device with its USB port in the device path.
ok
struct efi_device_path_usb_class {
struct efi_device_path dp;
u16 vendor_id;
u16 product_id;
u8 device_class;
u8 device_subclass;
u8 device_protocol;
} __packed;
So a correction need to be done in
./lib/efi_loader/efi_device_path.c:dp_fill()
case UCLASS_MASS_STORAGE:
case UCLASS_USB_HUB:
and ./lib/efi_loader/efi_device_path_to_text.c::dp_msging()
case DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS
to add USB port or other identifier (usb dev number for example) to
identify each device
and not only use PID/VID as today.
for example use device ID as it is done
UCLASS_NVME => dp->hba_port = desc->devnum;
UCLASS_IDE => dp->logical_unit_number = desc->devnum;
The way we currently create device paths is not good. We should traverse
the dm tree to the root and create a node for each dm device. The code
code for creating the individual nodes should be moved to uclasses.
I think that the USB port number can be found in USB DM in usb_device:
udev->portnr
PS: hub_address can be also found with udev->parent->devnum;
@Simon: is that ok for you?
efi_disk_probe()
efi_disk_create_raw()
efi_disk_add_dev()
efi_install_multiple_protocol_interfaces()
EFI_ALREADY_STARTED
If we create the same device path for two USB devices, this is a bug we
must fix.
OK,
so you can forget my serie
In case of error in probe, the 2nd key is unbound and deactivated for
the next usb commands even if the limitation is only for EFI.
This patch removes any return error in probe event callback;
if something occurs in EFI registration, the device is still probed.
Signed-off-by: Patrick Delaunay
---
lib/efi_loader/efi_disk.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8e7..8d53ba3bd27e 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -677,14 +677,18 @@ int efi_disk_probe(void *ctx, struct event *event)
desc = dev_get_uclass_plat(dev);
if (desc->uclass_id != UCLASS_EFI_LOADER) {
ret = efi_disk_create_raw(dev, agent_handle);
- if (ret)
- return -1;
+ if (ret) {
+ log_err("efi_disk_create_raw %s failed (%d)\n",
+ dev->name, ret);
This isn't a message a non-developer can easily understand.
+ return 0;
+ }
}
device_foreach_child(child, dev) {
ret = efi_disk_create_part(child, agent_handle);
if (ret)
- return -1;
+ log_err("efi_disk_create_part %s failed (%d)\n",
ditto.
Best regards
Heinrich
+ dev->name, ret);
}
return 0;
Patrick
Re: [PATCH 2/2] efi: remove error in efi_disk_remove
On 3/9/23 09:54, Heinrich Schuchardt wrote: On 3/8/23 14:26, Patrick Delaunay wrote: EFI has no reason to block the driver remove when the associated EFI resources failed to be released. This patch avoids DM issue when an EFI resource can't be released, for example if this resource wasn't created, for duplicated device name (error EFI_ALREADY_STARTED). Without this patch, the U-Boot device tree is not updated for "usb stop" command because EFI stack can't free a resource; in usb_stop(), the remove operation is stopped on first device_remove() error, including a device_notify() error on any chil The typical reason to return an error here is that the EFI device is still in use, i.e. a protocol installed on the EFI handle is opened by a child controller or driver. As long as the EFI handle cannot be removed we must not remove the linked DM device or we corrupt our data model. Best regards Heinrich Ok I get it now, Forget my serie Patrick
Re: [PATCH] dfu: mtd: mark bad the MTD block on erase error
Hi,
On 11/28/22 10:22, Patrick Delaunay wrote:
In the MTD DFU backend, it is needed to mark the NAND block bad when the
erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
This operation is not done in the MTD framework, but the bad block
tag (in BBM or in BBT) is required to avoid to write data on this block
in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
blocks, tested by mtd_block_isbad().
Without this patch, when the NAND block become bad on DFU write operation
- low probability on new NAND - the DFU write operation will always failed
because the failing block is never marked bad.
This patch also adds a test to avoid to request an erase operation on a
block already marked bad; this test is not performed in MTD framework
in mtd_erase().
Signed-off-by: Patrick Delaunay
---
drivers/dfu/dfu_mtd.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index c7075f12eca9..4fb02c4c806c 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -91,22 +91,32 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity
*dfu,
return -EIO;
}
+ /* Skip the block if it is bad, don't erase it again */
+ if (mtd_block_isbad(mtd, off)) {
"off" is the not correct offset here
=> need to be replace to "erase_op.addr"
+ erase_op.addr += mtd->erasesize;
+ continue;
+ }
+
ret = mtd_erase(mtd, &erase_op);
if (ret) {
- /* Abort if its not a bad block error */
- if (ret != -EIO) {
- printf("Failure while erasing at offset
0x%llx\n",
- erase_op.fail_addr);
- return 0;
+ /* If this is not -EIO, we have no idea what to
do. */
+ if (ret == -EIO) {
+ printf("Marking bad block at 0x%08llx
(%d)\n",
+ erase_op.fail_addr, ret);
+ ret = mtd_block_markbad(mtd,
erase_op.addr);
+ }
+ /* Abort if it is not -EIO or can't mark bad */
+ if (ret) {
+ printf("Failure while erasing at offset
0x%llx (%d)\n",
+ erase_op.fail_addr, ret);
+ return ret;
}
- printf("Skipping bad block at 0x%08llx\n",
- erase_op.addr);
} else {
remaining -= mtd->erasesize;
}
- /* Continue erase behind bad block */
+ /* Continue erase behind the current block */
erase_op.addr += mtd->erasesize;
}
}
Regards
Patrick
[PATCH 2/2] lmb: add max number of region in lmb_dump_region() output
Add the max number of region in lmb dump; this patch allows to
check the limit for usage of the LMB regions, memory or reserved.
Result on STM32MP157C-DK2:
STM32MP> bdinfo
.
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xd400-0xd7ff], 0x0400 bytes flags: 4
reserved[4][0xdcae5000-0xdfff], 0x0351b000 bytes flags: 0
reserved[5][0xddafb5b8-0xdfff], 0x02504a48 bytes flags: 0
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
lib/lmb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 8fbe453dfa9d..b2c233edb64e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -27,7 +27,7 @@ static void lmb_dump_region(struct lmb_region *rgn, char
*name)
enum lmb_flags flags;
int i;
- printf(" %s.cnt = 0x%lx\n", name, rgn->cnt);
+ printf(" %s.cnt = 0x%lx / max = 0x%lx\n", name, rgn->cnt, rgn->max);
for (i = 0; i < rgn->cnt; i++) {
base = rgn->region[i].base;
--
2.25.1
[PATCH 1/2] lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization are not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property's should is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
include/lmb.h | 20 +++-
lib/lmb.c | 2 +-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 7298c2ccc403..f70463ac5440 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -35,6 +35,24 @@ struct lmb_property {
enum lmb_flags flags;
};
+/*
+ * For regions size management, see LMB configuration in KConfig
+ * all the #if test are done with CONFIG_LMB_USE_MAX_REGIONS (boolean)
+ *
+ * case 1. CONFIG_LMB_USE_MAX_REGIONS is defined (legacy mode)
+ * => CONFIG_LMB_MAX_REGIONS is used to configure the region size,
+ * direclty in the array lmb_region.region[], with the same
+ * configuration for memory reion and reseserved region.
+ *
+ * case 2. CONFIG_LMB_USE_MAX_REGIONS is not defined, the size of each
+ * region is configurated *independently* with
+ * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
+ * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
+ * lmb_region.region is only a pointer to the correct buffer,
+ * initialized in lmb_init(). This configuration is useful to manage
+ * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ */
+
/**
* struct lmb_region - Description of a set of region.
*
@@ -68,7 +86,7 @@ struct lmb_region {
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#ifdef CONFIG_LMB_MEMORY_REGIONS
+#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
#endif
diff --git a/lib/lmb.c b/lib/lmb.c
index 2444b2a62121..8fbe453dfa9d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -110,7 +110,7 @@ void lmb_init(struct lmb *lmb)
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
lmb->memory.max = CONFIG_LMB_MAX_REGIONS;
lmb->reserved.max = CONFIG_LMB_MAX_REGIONS;
-#elif defined(CONFIG_LMB_MEMORY_REGIONS)
+#else
lmb->memory.max = CONFIG_LMB_MEMORY_REGIONS;
lmb->reserved.max = CONFIG_LMB_RESERVED_REGIONS;
lmb->memory.region = lmb->memory_regions;
--
2.25.1
[PATCH v2 2/2] lmb: add max number of region in lmb_dump_region() output
Add the max number of region in lmb dump; this patch allows to
check the limit for usage of the LMB regions, memory or reserved.
Result on STM32MP157C-DK2:
STM32MP> bdinfo
.
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xd400-0xd7ff], 0x0400 bytes flags: 4
reserved[4][0xdcae5000-0xdfff], 0x0351b000 bytes flags: 0
reserved[5][0xddafb5b8-0xdfff], 0x02504a48 bytes flags: 0
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
lib/lmb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 8fbe453dfa9d..b2c233edb64e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -27,7 +27,7 @@ static void lmb_dump_region(struct lmb_region *rgn, char
*name)
enum lmb_flags flags;
int i;
- printf(" %s.cnt = 0x%lx\n", name, rgn->cnt);
+ printf(" %s.cnt = 0x%lx / max = 0x%lx\n", name, rgn->cnt, rgn->max);
for (i = 0; i < rgn->cnt; i++) {
base = rgn->region[i].base;
--
2.25.1
[PATCH v2 1/2] lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- Remove CONFIG_LMB_XXX dependency on CONFIG_LMB as these defines are
used in lmb.h file, include by default to export the LMB API
and not only in LMB libary code. This modification is required to
avoid issue in API definition when CONFIG_LMB is not set.
- Fix some typo in commit message and in comment
include/lmb.h | 20 +++-
lib/Kconfig | 7 +++
lib/lmb.c | 2 +-
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 7298c2ccc403..07bf22144eac 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -35,6 +35,24 @@ struct lmb_property {
enum lmb_flags flags;
};
+/*
+ * For regions size management, see LMB configuration in KConfig
+ * all the #if test are done with CONFIG_LMB_USE_MAX_REGIONS (boolean)
+ *
+ * case 1. CONFIG_LMB_USE_MAX_REGIONS is defined (legacy mode)
+ * => CONFIG_LMB_MAX_REGIONS is used to configure the region size,
+ * directly in the array lmb_region.region[], with the same
+ * configuration for memory and reserved regions.
+ *
+ * case 2. CONFIG_LMB_USE_MAX_REGIONS is not defined, the size of each
+ * region is configurated *independently* with
+ * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
+ * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
+ * lmb_region.region is only a pointer to the correct buffer,
+ * initialized in lmb_init(). This configuration is useful to manage
+ * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ */
+
/**
* struct lmb_region - Description of a set of region.
*
@@ -68,7 +86,7 @@ struct lmb_region {
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#ifdef CONFIG_LMB_MEMORY_REGIONS
+#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 83e5edd73b0e..da6c7cd5f628 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -1027,7 +1027,6 @@ config LMB
config LMB_USE_MAX_REGIONS
bool "Use a common number of memory and reserved regions in lmb lib"
- depends on LMB
default y
help
Define the number of supported memory regions in the library logical
@@ -1037,7 +1036,7 @@ config LMB_USE_MAX_REGIONS
config LMB_MAX_REGIONS
int "Number of memory and reserved regions in lmb lib"
- depends on LMB && LMB_USE_MAX_REGIONS
+ depends on LMB_USE_MAX_REGIONS
default 16
help
Define the number of supported regions, memory and reserved, in the
@@ -1045,7 +1044,7 @@ config LMB_MAX_REGIONS
config LMB_MEMORY_REGIONS
int "Number of memory regions in lmb lib"
- depends on LMB && !LMB_USE_MAX_REGIONS
+ depends on !LMB_USE_MAX_REGIONS
default 8
help
Define the number of supported memory regions in the library logical
@@ -1054,7 +1053,7 @@ config LMB_MEMORY_REGIONS
config LMB_RESERVED_REGIONS
int "Number of reserved regions in lmb lib"
- depends on LMB && !LMB_USE_MAX_REGIONS
+ depends on !LMB_USE_MAX_REGIONS
default 8
help
Define the number of supported reserved regions in the library logical
diff --git a/lib/lmb.c b/lib/lmb.c
index 2444b2a62121..8fbe453dfa9d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -110,7 +110,7 @@ void lmb_init(struct lmb *lmb)
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
lmb->memory.max = CONFIG_LMB_MAX_REGIONS;
lmb->reserved.max = CONFIG_LMB_MAX_REGIONS;
-#elif defined(CONFIG_LMB_MEMORY_REGIONS)
+#else
lmb->memory.max = CONFIG_LMB_MEMORY_REGIONS;
lmb->reserved.max = CONFIG_LMB_RESERVED_REGIONS;
lmb->memory.region = lmb->memory_regions;
--
2.25.1
Re: [PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
Hi
On 3/22/23 12:26, haibo.c...@nxp.com wrote:
From: Haibo Chen
dm_gpio_set_dir_flags() will clear GPIOD_MASK_DIR and set new flags.
But there are cases like i2c_deblock_gpio_loop() will do like this:
-first conifg GPIO(SDA) output with GPIOD_ACTIVE_LOW
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW |
GPIOD_IS_OUT_ACTIVE);
-then config GPIO input
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
-then get the GPIO input value:
dm_gpio_get_value(pin);
When config the GPIO input, only set GPIOD_IS_IN, but unfortunately
since the previous GPIOD_ACTIVE_LOW is not cleared, still keep in
flags, make the value from dm_gpio_get_value() not logic correct.
So add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR to avoid this issue.
Signed-off-by: Haibo Chen
---
include/asm-generic/gpio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index dd0bdf2315..903b237aac 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -131,7 +131,7 @@ struct gpio_desc {
/* Flags for updating the above */
#define GPIOD_MASK_DIR(GPIOD_IS_OUT | GPIOD_IS_IN | \
- GPIOD_IS_OUT_ACTIVE)
+GPIOD_IS_OUT_ACTIVE | GPIOD_ACTIVE_LOW)
#define GPIOD_MASK_DSTYPE (GPIOD_OPEN_DRAIN | GPIOD_OPEN_SOURCE)
#define GPIOD_MASK_PULL (GPIOD_PULL_UP | GPIOD_PULL_DOWN)
I think you are breaking the management of GPIOD_ACTIVE_LOW, provided by
device tree in the GPIO uclass:
because the modified GPIOD_MASK_DIR is used in other location
normally GPIOD_ACTIVE_LOW is saved in desc->flags
it is the "desciptor flags" and must be not cleary by normal API
see gpio_xlate_offs_flags() => gpio_flags_xlate()
For example in gpio_request_tail(), in the line:
/* Keep any direction flags provided by the devicetree */
ret = dm_gpio_set_dir_flags(desc,
flags | (desc->flags& GPIOD_MASK_DIR));
With your patch the descriptor flags is cleared / so DT information is lost.
For me GPIOD_ACTIVE_LOW must be managed carefully to avoid side effect.
and if you inverse the PIN logical in device tree (GPIOD_ACTIVE_LOW) it
is normal to inverse it for INPUT and OUTPUT
it is managed in GPIO U-Class
=> dm_gpio_set_dir_flagsshould not cleared this flag GPIOD_ACTIVE_LOW
you can change the caller ?
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit) { if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN); else dm_gpio_set_dir_flags(pin,
GPIOD_IS_OUT | GPIOD_ACTIVE_LOW | GPIOD_IS_OUT_ACTIVE); }
=>
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit)
{
if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
else
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT);
}
The output value is the same => GPIOD_ACTIVE_LOW and GPIOD_IS_OUT_ACTIVE
not active
but you don't need to modify GPIOD_ACTIVE_LOW outside the GPIO uclass.
Patrick
Re: [PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
Hi,
On 3/23/23 09:17, Bough Chen wrote:
-Original Message-
From: Patrick DELAUNAY
Sent: 2023年3月23日 3:11
To: Bough Chen ; al.koc...@gmail.com; h...@denx.de;
s...@chromium.org; and...@aj.id.au; patrice.chot...@foss.st.com;
sam...@sholland.org; ma...@denx.de
Cc: dl-uboot-imx ; u-boot@lists.denx.de
Subject: Re: [PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
Hi
On 3/22/23 12:26, haibo.c...@nxp.com wrote:
From: Haibo Chen
dm_gpio_set_dir_flags() will clear GPIOD_MASK_DIR and set new flags.
But there are cases like i2c_deblock_gpio_loop() will do like this:
-first conifg GPIO(SDA) output with GPIOD_ACTIVE_LOW
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW |
GPIOD_IS_OUT_ACTIVE);
-then config GPIO input
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
-then get the GPIO input value:
dm_gpio_get_value(pin);
When config the GPIO input, only set GPIOD_IS_IN, but unfortunately
since the previous GPIOD_ACTIVE_LOW is not cleared, still keep in
flags, make the value from dm_gpio_get_value() not logic correct.
So add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR to avoid this issue.
Signed-off-by: Haibo Chen
---
include/asm-generic/gpio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index dd0bdf2315..903b237aac 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -131,7 +131,7 @@ struct gpio_desc {
/* Flags for updating the above */
#define GPIOD_MASK_DIR (GPIOD_IS_OUT | GPIOD_IS_IN | \
- GPIOD_IS_OUT_ACTIVE)
+GPIOD_IS_OUT_ACTIVE | GPIOD_ACTIVE_LOW)
#define GPIOD_MASK_DSTYPE(GPIOD_OPEN_DRAIN |
GPIOD_OPEN_SOURCE)
#define GPIOD_MASK_PULL (GPIOD_PULL_UP |
GPIOD_PULL_DOWN)
I think you are breaking the management of GPIOD_ACTIVE_LOW, provided by
device tree in the GPIO uclass:
because the modified GPIOD_MASK_DIR is used in other location
normally GPIOD_ACTIVE_LOW is saved in desc->flags
it is the "desciptor flags" and must be not cleary by normal API
see gpio_xlate_offs_flags() => gpio_flags_xlate()
For example in gpio_request_tail(), in the line:
/* Keep any direction flags provided by the devicetree */ ret =
dm_gpio_set_dir_flags(desc, flags | (desc->flags& GPIOD_MASK_DIR)); With
your patch the descriptor flags is cleared / so DT information is lost.
For me GPIOD_ACTIVE_LOW must be managed carefully to avoid side effect.
and if you inverse the PIN logical in device tree (GPIOD_ACTIVE_LOW) it is
normal to inverse it for INPUT and OUTPUT it is managed in GPIO U-Class =>
dm_gpio_set_dir_flagsshould not cleared this flag GPIOD_ACTIVE_LOW you can
change the caller ?
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit) { if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN); else dm_gpio_set_dir_flags(pin,
GPIOD_IS_OUT | GPIOD_ACTIVE_LOW | GPIOD_IS_OUT_ACTIVE); } =>
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit) {
if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
else
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT); }
Here, for i2c-deblock, when call dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT), the
software actually want to config the gpio at output, and config the output to
low level.
This means in dts, need to config the i2c gpio as GPIO_ACTIVE_HIGH, then when
call dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT), it finally config the value to
0, which means low level.
But from user point, we usually take the i2c gpio as GPIO_ACTIVE_LOW, seems a
bit conflict.
Any thoughts? Or just use my first patch?
I am lost (I am not dig in I2C GPIO part)
but if I assume that GPIO_ACTIVE_HIGH is NOT activated in DT
(because the GPIO line is directly connected to the I2C device)
Then GPIO line = HIGH => GPIO value is 1 for uclass (input or output)
=> dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT);
if you want to have output LOW
=> dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
if you want to have output HIGH
You can select what it is expected in I2C
input => GPIO input selection
output => ouput value selected by bit
for example
i2c_gpio_set_pin(struct gpio_desc *pin, int input, int bit) {
if (input)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
else if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
else
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT);
}
if the GPIO is inverted in DT (that means some inverse logic exist on
hardware), with GPIO_ACTIVE_LOW
=> the result is inverted as expected for INPUT and OUTPUT
if the logic is always inverted => you need to change the caller
(request 1 instead 0)
For me the SW side in U-boot should be not take care of GPIO_ACTIVE_
Re: [PATCH v2] board: stm32mp1: add splash screen on dk2
Hi Dario,
On 7/4/23 19:31, Dario Binacchi wrote:
Display the STMicroelectronics logo.
Signed-off-by: Dario Binacchi
---
Changes in v2:
- move "splash.h" and "st_logo_data.h" headers before "syscon.h" in order
to keep includes sorted alphabetically.
- remove "logo" variable and pass
"(ulong)stmicroelectronics_uboot_logo_8bit_rle"
directly to the bmp_display() function.
board/st/stm32mp1/stm32mp1.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 1a1b1844c8c0..ebd3948d519c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -31,8 +31,11 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -684,6 +687,14 @@ int board_init(void)
fw_images[0].fw_name = u"STM32MP-FIP";
fw_images[0].image_index = 1;
#endif
+
+ if (IS_ENABLED(CONFIG_CMD_BMP)) {
+ if (board_is_stm32mp15x_dk2()) {
+
bmp_display((ulong)stmicroelectronics_uboot_logo_8bit_rle,
+ BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
+ }
+ }
+
return 0;
}
I think "include/st_logo_data.h" should be not directly used for STM32 MPU
it is a obsolete way to have splash screen, used by STM32 MCU as STM32F7.
And direct management for splash it is not really needed in board code,
as it is already managed in VIDEO framework with CONFIG_VIDEO_LOGO
enabled by default since commit 845d71ce36ab5ae2cef4542b221851cde199
("video: Show the U-Boot logo by default")
and with CONFIG_SPLASH_SCREEN
see stdio_init_tables()
=> splash_display();
position is managed with:
- CONFIG_SPLASH_SCREEN_ALIGN
- variable: "splashpos=m,m"
But by default the U-Boot logo (yellow submarine) is used for VIDEO LOGO
(SPLASH_DECL(u_boot_logo) in video uclass
or denx for SPLASH is used in tools/Makefile
# Generic logo
ifeq ($(LOGO_BMP),)
LOGO_BMP= $(srctree)/$(src)/logos/denx.bmp
# Use board logo and fallback to vendor
ifneq ($(wildcard $(srctree)/$(src)/logos/$(BOARD).bmp),)
LOGO_BMP= $(srctree)/$(src)/logos/$(BOARD).bmp
else
ifneq ($(wildcard $(srctree)/$(src)/logos/$(VENDOR).bmp),)
LOGO_BMP= $(srctree)/$(src)/logos/$(VENDOR).bmp
endif
endif
The STMicroelectronics logo image can be integrated in this directory with
VENDOR="st"
BOARD="stm32mp1"
We need to add it ./tools/logos/st.bmp
I can propose something, for all ST board STM32MP1x, not only DK2
Patrick
[PATCH] ARM: dts: stm32mp: alignment with v6.4
Device tree alignment with Linux kernel v6.4.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp13-pinctrl.dtsi | 129
arch/arm/dts/stm32mp131.dtsi| 99 -
arch/arm/dts/stm32mp135f-dk.dts | 42 -
arch/arm/dts/stm32mp15-pinctrl.dtsi | 34
arch/arm/dts/stm32mp151.dtsi| 4 +-
arch/arm/dts/stm32mp157a-dk1.dts| 3 -
arch/arm/dts/stm32mp157c-dk2.dts| 3 -
arch/arm/dts/stm32mp157c-ed1.dts| 17 +---
arch/arm/dts/stm32mp157c-ev1.dts| 9 +-
arch/arm/dts/stm32mp15xx-dkx.dtsi | 15 ++--
10 files changed, 299 insertions(+), 56 deletions(-)
diff --git a/arch/arm/dts/stm32mp13-pinctrl.dtsi
b/arch/arm/dts/stm32mp13-pinctrl.dtsi
index b2dce3a29f39..27e0c3826789 100644
--- a/arch/arm/dts/stm32mp13-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp13-pinctrl.dtsi
@@ -258,4 +258,133 @@
bias-disable;
};
};
+
+ uart4_idle_pins_a: uart4-idle-0 {
+ pins1 {
+ pinmux = ; /* UART4_TX */
+ };
+ pins2 {
+ pinmux = ; /* UART4_RX */
+ bias-disable;
+ };
+ };
+
+ uart4_sleep_pins_a: uart4-sleep-0 {
+ pins {
+ pinmux = , /* UART4_TX */
+; /* UART4_RX */
+ };
+ };
+
+ uart8_pins_a: uart8-0 {
+ pins1 {
+ pinmux = ; /* UART8_TX */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = ; /* UART8_RX */
+ bias-pull-up;
+ };
+ };
+
+ uart8_idle_pins_a: uart8-idle-0 {
+ pins1 {
+ pinmux = ; /* UART8_TX */
+ };
+ pins2 {
+ pinmux = ; /* UART8_RX */
+ bias-pull-up;
+ };
+ };
+
+ uart8_sleep_pins_a: uart8-sleep-0 {
+ pins {
+ pinmux = , /* UART8_TX */
+; /* UART8_RX */
+ };
+ };
+
+ usart1_pins_a: usart1-0 {
+ pins1 {
+ pinmux = , /* USART1_TX */
+; /* USART1_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = , /* USART1_RX */
+; /* USART1_CTS_NSS
*/
+ bias-pull-up;
+ };
+ };
+
+ usart1_idle_pins_a: usart1-idle-0 {
+ pins1 {
+ pinmux = , /* USART1_TX */
+; /*
USART1_CTS_NSS */
+ };
+ pins2 {
+ pinmux = ; /* USART1_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins3 {
+ pinmux = ; /* USART1_RX */
+ bias-pull-up;
+ };
+ };
+
+ usart1_sleep_pins_a: usart1-sleep-0 {
+ pins {
+ pinmux = , /* USART1_TX */
+, /* USART1_RTS
*/
+, /*
USART1_CTS_NSS */
+; /* USART1_RX */
+ };
+ };
+
+ usart2_pins_a: usart2-0 {
+ pins1 {
+ pinmux = , /* USART2_TX */
+; /* USART2_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = , /* USART2_RX */
+; /*
USART2_CTS_NSS */
+ bias-disable;
+ };
+ };
+
+ usart2_idle_pins_a: usart2-idle-0 {
+ pins1 {
+ pinmux = , /* USART2_TX
*/
+; /*
USART2_CTS_NSS */
+ };
+ pins2 {
+ pinmux = ; /* USART2_RTS */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins3 {
+ pinmux = ; /* USART2_RX */
+ bias-disable;
+ };
+ };
+
+ usart2_sleep_pins_a: usart2-sleep-0 {
+ pins {
+ pinmux = , /* USART2_TX
*/
+, /* USART2_RTS
*/
+
[PATCH 1/2] ARM: dts: sm32mp15: remove shmem for scmi-optee
Since OP-TEE commit 89ba3422ee80 ("plat-stm32mp1: scmi_server: default
use OP-TEE shared memory"), integrated in OP-TEE 3.22.0-rc1
the default configuration for STM32MP15x SoCs changes,
CFG_STM32MP1_SCMI_SHM_SYSRAM is disabled by default and the OP-TEE SMCI
server uses ithe OP-TEE native shared memory registered by clients.
To be compatible by default with this configuration and the next OP-TEE
version, this patch removes the SHMEM in the SCMI configuration and the
associated reserved memory in the last 4KByte page of SRAM,
in the STM32MP15 device tree.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp15-scmi.dtsi | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/dts/stm32mp15-scmi.dtsi b/arch/arm/dts/stm32mp15-scmi.dtsi
index 543f24c2f4f6..ad2584213d99 100644
--- a/arch/arm/dts/stm32mp15-scmi.dtsi
+++ b/arch/arm/dts/stm32mp15-scmi.dtsi
@@ -16,7 +16,6 @@
#address-cells = <1>;
#size-cells = <0>;
linaro,optee-channel-id = <0>;
- shmem = <&scmi_shm>;
scmi_clk: protocol@14 {
reg = <0x14>;
@@ -60,21 +59,6 @@
};
};
};
-
- soc {
- scmi_sram: sram@2000 {
- compatible = "mmio-sram";
- reg = <0x2000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x2000 0x1000>;
-
- scmi_shm: scmi-sram@0 {
- compatible = "arm,scmi-shmem";
- reg = <0 0x80>;
- };
- };
- };
};
®11 {
--
2.25.1
[PATCH 2/2] ARM: dts: sm32mp13: remove shmem for scmi-optee
CFG_STM32MP1_SCMI_SHM_SYSRAM will be disabled by default for STM32MP13x
SoCs in next OP-TEE version and the OP-TEE SMCI server uses the OP-TEE
native shared memory registered by clients.
To be compatible by default with this configuration this patch removes
the shared memory in the SCMI configuration and the associated reserved
memory in SRAM.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp13-u-boot.dtsi | 8
arch/arm/dts/stm32mp131.dtsi | 14 --
2 files changed, 22 deletions(-)
diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
b/arch/arm/dts/stm32mp13-u-boot.dtsi
index 726cd1a7e479..aa5cfc6e41d5 100644
--- a/arch/arm/dts/stm32mp13-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
@@ -108,14 +108,6 @@
bootph-all;
};
-&scmi_shm {
- bootph-all;
-};
-
-&scmi_sram {
- bootph-all;
-};
-
&syscfg {
bootph-all;
};
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index d94ba2547267..f1810c9eb704 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -40,7 +40,6 @@
#address-cells = <1>;
#size-cells = <0>;
linaro,optee-channel-id = <0>;
- shmem = <&scmi_shm>;
scmi_clk: protocol@14 {
reg = <0x14>;
@@ -106,19 +105,6 @@
interrupt-parent = <&intc>;
ranges;
- scmi_sram: sram@2000 {
- compatible = "mmio-sram";
- reg = <0x2000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x2000 0x1000>;
-
- scmi_shm: scmi-sram@0 {
- compatible = "arm,scmi-shmem";
- reg = <0 0x80>;
- };
- };
-
timers2: timer@4000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.25.1
[PATCH] board: stm32mp1: add splash screen with stmicroelectronics logo
Display the STMicroelectronics logo with features VIDEO_LOGO and
SPLASH_SCREEN on STMicroelectronics boards.
With CONFIG_SYS_VENDOR = "st", the logo st.bmp is selected, loaded at the
address indicated by splashimage and centered with "splashpos=m,m".
Signed-off-by: Patrick Delaunay
---
MAINTAINERS | 1 +
configs/stm32mp15_basic_defconfig | 3 +++
configs/stm32mp15_defconfig | 3 +++
configs/stm32mp15_trusted_defconfig | 3 +++
include/configs/stm32mp15_st_common.h | 4 +++-
tools/logos/st.bmp| Bin 0 -> 18244 bytes
6 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 tools/logos/st.bmp
diff --git a/MAINTAINERS b/MAINTAINERS
index d724b6467344..dfe9409bc7fe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -578,6 +578,7 @@ F: include/dt-bindings/clock/stm32mp*
F: include/dt-bindings/pinctrl/stm32-pinfunc.h
F: include/dt-bindings/reset/stm32mp*
F: include/stm32_rcc.h
+F: tools/logos/st.bmp
F: tools/stm32image.c
N: stm
N: stm32
diff --git a/configs/stm32mp15_basic_defconfig
b/configs/stm32mp15_basic_defconfig
index 424ae5dbdfaf..9ea5aaa7145a 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -171,6 +171,7 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
CONFIG_USB_GADGET_DWC2_OTG=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
@@ -178,6 +179,8 @@ CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index 2700b5c49910..4d0a81f8a871 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -147,6 +147,7 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
CONFIG_USB_GADGET_DWC2_OTG=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
@@ -154,6 +155,8 @@ CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
diff --git a/configs/stm32mp15_trusted_defconfig
b/configs/stm32mp15_trusted_defconfig
index 5b94e0c6d2e7..0a7d8624858d 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -147,6 +147,7 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483
CONFIG_USB_GADGET_PRODUCT_NUM=0x5720
CONFIG_USB_GADGET_DWC2_OTG=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_LCD_RAYDIUM_RM68200=y
@@ -154,6 +155,8 @@ CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_SPLASH_SCREEN=y
+CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
diff --git a/include/configs/stm32mp15_st_common.h
b/include/configs/stm32mp15_st_common.h
index b45982a35b8c..60838cb0e3f0 100644
--- a/include/configs/stm32mp15_st_common.h
+++ b/include/configs/stm32mp15_st_common.h
@@ -10,7 +10,9 @@
#define STM32MP_BOARD_EXTRA_ENV \
"usb_pgood_delay=2000\0" \
- "console=ttySTM0\0"
+ "console=ttySTM0\0" \
+ "splashimage=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+ "splashpos=m,m\0"
#include
diff --git a/tools/logos/st.bmp b/tools/logos/st.bmp
new file mode 100644
index
..f59d3c5cef6b8bce5213a1ef42a9cdaa3c5dbc58
GIT binary patch
literal 18244
zcmeHvcUV-((s!LXVPJqEg9Hfz>WVo>42Tg_%$P;Qw63nQ=A5&b5zOKWq9|ZOKv57>
z1OZ9TpyV(E6ZYo#-mm%$0|+yFpYPxIdH1=!JLh!$s;j%JtE=i1cZ}cI@xcG%#Q^+>
zzm`w{<=7}Nzy`p116Ueq+Hd$w+L-avH{yT(zy1-lp`PqUgI^a@nCfW@{=J-FdS5q~
zIiL&79_$HohV_B~uf8yE)BsrEJs1}H41>kvyeSFAjj8m&}6=feT>cvV{;5v=}x8FNMu30%6Ol
zAlSNkIc!@K4BOYPgdIPvf}QKuz^?T_!tM=gVb8{Ous38q?EB?s*uQB59M}>92eM&;C94ih`bUGkyj(&&b0{m_4*aKd;Kch
zy>ShqZeEAzTQ?y3_6@jq`zFLh-h!Arx8eS;k??@DyLTWq>Q{IeeHR|xi-NeAXo$Oi
z58|;UJcxmW*!%D}_5nP3i0x4p9h7cea?p>(h5F9aX|qT7ZyNCVIhdH!}uBwEZsw$|du7cX?YN)NLhPs*>sH?4k`r2BkuOqDvWc8%ggIq?M3>rw2
z%b}69h6YfO*4PM2g#uJcC8$-Tso*y?X=?cGH#Pj>x8L9ofA|gl_=i8hpZ@qq_|u>M
z1b-&&&wqx$koK3qz+XxGD`|g)zx|E0zro*0`}^PFAEf=`AMnqA{uBQ7FVg-6|0eC<
z|AznhpZ|gX{O3RLAN5i-{NKO-m#o0Q)WE5}UJG8EW2*)>H+=npH!ueGm%LYIO$4}0
z-p7mv%d;)-b7lg>koS-L!0od3y-=Am3*d4cSe1ZKBE2%UUEhqoV6_E=Ter=22lr+i
ztwer~05sLP)jJ%Uyc4v%V^n3oZnE78!d<%qJhb@#sO?dX7yjTH#>=63j-3R~ms&li
z@1C$UzSZ;B*U<^ZP0y{hnL}RHAMVHHf+_wgdT{zmP7@XB$=Tg+WGLSg;|;dwTJ>
Re: [PATCH v2] board: stm32mp1: add splash screen on dk2
Hi,
On 7/8/23 19:19, Dario Binacchi wrote:
Hi Patrick,
On Wed, Jul 5, 2023 at 2:09 PM Patrick DELAUNAY
wrote:
Hi Dario,
On 7/4/23 19:31, Dario Binacchi wrote:
Display the STMicroelectronics logo.
Signed-off-by: Dario Binacchi
---
Changes in v2:
- move "splash.h" and "st_logo_data.h" headers before "syscon.h" in order
to keep includes sorted alphabetically.
- remove "logo" variable and pass
"(ulong)stmicroelectronics_uboot_logo_8bit_rle"
directly to the bmp_display() function.
board/st/stm32mp1/stm32mp1.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 1a1b1844c8c0..ebd3948d519c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -31,8 +31,11 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -684,6 +687,14 @@ int board_init(void)
fw_images[0].fw_name = u"STM32MP-FIP";
fw_images[0].image_index = 1;
#endif
+
+ if (IS_ENABLED(CONFIG_CMD_BMP)) {
+ if (board_is_stm32mp15x_dk2()) {
+ bmp_display((ulong)stmicroelectronics_uboot_logo_8bit_rle,
+ BMP_ALIGN_CENTER, BMP_ALIGN_CENTER);
+ }
+ }
+
return 0;
}
I think "include/st_logo_data.h" should be not directly used for STM32 MPU
it is a obsolete way to have splash screen, used by STM32 MCU as STM32F7.
And direct management for splash it is not really needed in board code,
as it is already managed in VIDEO framework with CONFIG_VIDEO_LOGO
enabled by default since commit 845d71ce36ab5ae2cef4542b221851cde199
("video: Show the U-Boot logo by default")
and with CONFIG_SPLASH_SCREEN
see stdio_init_tables()
=> splash_display();
position is managed with:
- CONFIG_SPLASH_SCREEN_ALIGN
- variable: "splashpos=m,m"
But by default the U-Boot logo (yellow submarine) is used for VIDEO LOGO
(SPLASH_DECL(u_boot_logo) in video uclass
or denx for SPLASH is used in tools/Makefile
# Generic logo
ifeq ($(LOGO_BMP),)
LOGO_BMP= $(srctree)/$(src)/logos/denx.bmp
# Use board logo and fallback to vendor
ifneq ($(wildcard $(srctree)/$(src)/logos/$(BOARD).bmp),)
LOGO_BMP= $(srctree)/$(src)/logos/$(BOARD).bmp
else
ifneq ($(wildcard $(srctree)/$(src)/logos/$(VENDOR).bmp),)
LOGO_BMP= $(srctree)/$(src)/logos/$(VENDOR).bmp
endif
endif
The STMicroelectronics logo image can be integrated in this directory with
VENDOR="st"
BOARD="stm32mp1"
We need to add it ./tools/logos/st.bmp
I can propose something, for all ST board STM32MP1x, not only DK2
Thanks for the explanations.
You are welcome.
I propose to replace you propsal by the patch I just sent today:
http://patchwork.ozlabs.org/project/uboot/list/?series=363143&state=*
[PATCH] board: stm32mp1: add splash screen with stmicroelectronics logo
I test ir on STM32MP157C-DK2
Tell me if it is OK on your side.
Patrick
Re: [PATCH] ARM: stm32: Inhibit PDDS because CSTBYDIS is set
Hi, On 7/6/23 23:32, Marek Vasut wrote: The PWR_MPUCR CSTBYDIS bit is set, therefore the CA cores can never enter CStandby state and would always end up in CStop state. Clear the PDDS bit, which indicates the CA cores can enter CStandby state as it makes little sense to keep it set with CSTBYDIS also set. This does however fix a problem too. When both PWR_MPUCR and PWR_MCUCR PDDS bits are set, then the chip enters CStandby state even though the PWR_MCUCR CSTBYDIS is set. Clearing the PWR_MPUCR PDDS prevents that from happening. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay Cc: uboot-st...@st-md-mailman.stormreply.com --- arch/arm/mach-stm32mp/psci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c index 50e3fc4ae45..79734b5289b 100644 --- a/arch/arm/mach-stm32mp/psci.c +++ b/arch/arm/mach-stm32mp/psci.c @@ -754,7 +754,7 @@ void __secure psci_system_suspend(u32 __always_unused function_id, setbits_le32(STM32_RCC_BASE + RCC_MP_CIER, RCC_MP_CIFR_WKUPF); setbits_le32(STM32_PWR_BASE + PWR_MPUCR, -PWR_MPUCR_CSSF | PWR_MPUCR_CSTDBYDIS | PWR_MPUCR_PDDS); +PWR_MPUCR_CSSF | PWR_MPUCR_CSTDBYDIS); saved_mcudivr = readl(STM32_RCC_BASE + RCC_MCUDIVR); saved_pll3cr = readl(STM32_RCC_BASE + RCC_PLL3CR); Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] ARM: stm32: Fix OF_LIST on DHCOR
Hi, On 7/10/23 23:48, Marek Vasut wrote: On 6/16/23 14:18, Marek Vasut wrote: On 6/16/23 13:44, Patrice CHOTARD wrote: On 5/12/23 15:58, Patrick DELAUNAY wrote: Hi, On 5/5/23 02:11, Tom Rini wrote: The ITS file used to build the images here lists three dtb files as being used. Today, these are built by the logic that will over-build dtb files based on SOC/etc symbols being set. To future proof this platform and be generally correct, we list all 3 of the device trees used here in OF_LIST. Cc: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard Signed-off-by: Tom Rini --- configs/stm32mp15_dhcor_basic_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index b54ff9301461..d4786500271a 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -92,6 +92,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=nor0:256k(fsbl1),256k(fsbl2),1408k(uboot),64k( # CONFIG_ISO_PARTITION is not set # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_OF_LIVE=y +CONFIG_OF_LIST="stm32mp15xx-dhcor-avenger96 stm32mp15xx-dhcor-testbench stm32mp15xx-dhcor-drc-compact" 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_SYS_REDUNDAND_ENVIRONMENT=y Reviewed-by: Patrick Delaunay Thanks Patrick Applied to u-boot-stm/next Since this is a bugfix, should be for current. I do not see this bugfix in u-boot 2023.07 release, even though ST has been notified this is a bugfix for that release a month before the release. Why ? Sorry, it is is a mistake. Patrice miss your previous message and we don't sent a new pull request for v2023.07 bugfix. Patrick
Re: [PATCH v2 1/2] arm: stm32mp: Really fix compilation issue when SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled
Hi,
On 8/22/23 09:51, Bhupesh Sharma wrote:
While 23e20b2fa6 ("arm: stm32mp: Fix compilation issue when
SYS_DCACHE_OFF and/or SYS_DCACHE_SYS are enabled") tried fixing
this issue, fix it really by adding #if checks for SYS_ICACHE_OFF
and SYS_DCACHE_OFF.
Cc: Patrice Chotard
Cc: Patrick Delaunay
Signed-off-by: Bhupesh Sharma
---
arch/arm/mach-stm32mp/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index e2f67fc423..8ed065b389 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -90,10 +90,10 @@ static void early_enable_caches(void)
if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
return;
- if (!(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF))) {
+#if !(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
gd->arch.tlb_size = PGTABLE_SIZE;
gd->arch.tlb_addr = (unsigned long)&early_tlb;
- }
+#endif
/* enable MMU (default configuration) */
dcache_enable();
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 1/3] configs: stm32f746-disco: limit resolution to 480x272
Hi,
On 8/20/23 18:24, Dario Binacchi wrote:
The patch fixes the y-resolution, which was causing the creation of a
framebuffer larger than actually needed, resulting in memory waste.
Fixes: cc1b0e7b8e55b ("board: Add display to STM32F746 SoC discovery board")
Signed-off-by: Dario Binacchi
---
configs/stm32f746-disco_defconfig | 2 +-
configs/stm32f746-disco_spl_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/stm32f746-disco_defconfig
b/configs/stm32f746-disco_defconfig
index bb98ee307a6e..8403679d7fa6 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -59,7 +59,7 @@ CONFIG_VIDEO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_MAX_XRES=480
-CONFIG_VIDEO_STM32_MAX_YRES=640
+CONFIG_VIDEO_STM32_MAX_YRES=272
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_VIDEO_BMP_RLE8=y
diff --git a/configs/stm32f746-disco_spl_defconfig
b/configs/stm32f746-disco_spl_defconfig
index 84aaec1e3390..50c2a36784af 100644
--- a/configs/stm32f746-disco_spl_defconfig
+++ b/configs/stm32f746-disco_spl_defconfig
@@ -85,7 +85,7 @@ CONFIG_VIDEO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_MAX_XRES=480
-CONFIG_VIDEO_STM32_MAX_YRES=640
+CONFIG_VIDEO_STM32_MAX_YRES=272
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_VIDEO_BMP_RLE8=y
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 2/3] board: stm32f746-disco: refactor the display of the ST logo
Hi
On 8/20/23 18:24, Dario Binacchi wrote:
The patch removes the legacy mode of displaying the ST logo and adopts
the approach introduced by the commit 284b08fb51b6 ("board: stm32mp1: add
splash screen with stmicroelectronics logo"). It was necessary to use a
specific logo for the stm32f746-disco board.
Furthermore, the previous version didn't properly center the logo, hiding
its upper part.
Signed-off-by: Dario Binacchi
---
board/st/stm32f746-disco/stm32f746-disco.c | 6 --
configs/stm32f746-disco_defconfig | 2 +-
configs/stm32f746-disco_spl_defconfig | 2 +-
include/configs/stm32f746-disco.h | 7 ++-
tools/logos/stm32f746-disco.bmp| Bin 0 -> 18052 bytes
5 files changed, 8 insertions(+), 9 deletions(-)
create mode 100644 tools/logos/stm32f746-disco.bmp
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 3/3] Remove the hardcoded ST logo no longer in use
Hi, On 8/20/23 18:24, Dario Binacchi wrote: The patch removes the hardcoded ST logo from the code, as it is no longer used. Signed-off-by: Dario Binacchi --- include/st_logo_data.h | 3265 1 file changed, 3265 deletions(-) delete mode 100644 include/st_logo_data.h Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] configs: stm32f769-disco: Enable VIDEO_LOGO flag
Hi,
On 8/25/23 18:24, Patrice Chotard wrote:
The patch removes the legacy mode of displaying the ST logo and adopts
the approach introduced by the commit 284b08fb51b6 ("board: stm32mp1: add
splash screen with stmicroelectronics logo").
Signed-off-by: Patrice Chotard
---
configs/stm32f769-disco_defconfig | 2 +-
configs/stm32f769-disco_spl_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/stm32f769-disco_defconfig
b/configs/stm32f769-disco_defconfig
index 72ef133fe4a..20dbb1af630 100644
--- a/configs/stm32f769-disco_defconfig
+++ b/configs/stm32f769-disco_defconfig
@@ -56,6 +56,7 @@ CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_STM32=y
@@ -64,7 +65,6 @@ CONFIG_VIDEO_STM32_MAX_XRES=480
CONFIG_VIDEO_STM32_MAX_YRES=800
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
diff --git a/configs/stm32f769-disco_spl_defconfig
b/configs/stm32f769-disco_spl_defconfig
index dd17cad7362..a5298e7cdc1 100644
--- a/configs/stm32f769-disco_spl_defconfig
+++ b/configs/stm32f769-disco_spl_defconfig
@@ -82,6 +82,7 @@ CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_SPL_TIMER=y
CONFIG_VIDEO=y
+CONFIG_VIDEO_LOGO=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y
CONFIG_VIDEO_STM32=y
@@ -90,7 +91,6 @@ CONFIG_VIDEO_STM32_MAX_XRES=480
CONFIG_VIDEO_STM32_MAX_YRES=800
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
-CONFIG_VIDEO_BMP_RLE8=y
CONFIG_BMP_16BPP=y
CONFIG_BMP_24BPP=y
CONFIG_BMP_32BPP=y
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 6/6] stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32
Hi Simon,
On 8/24/23 17:14, Tom Rini wrote:
On Thu, Aug 24, 2023 at 05:09:07PM +0200, Marek Vasut wrote:
On 8/24/23 16:25, Tom Rini wrote:
On Thu, Aug 24, 2023 at 05:12:45AM +0200, Marek Vasut wrote:
On 8/24/23 05:02, Simon Glass wrote:
A '.stm32' extension is not allowed anymore, so change it.
Why?
This will likely break a huge amount of scripts, I'm tempted to NAK it
unless there is a very good reason.
This is in the cover letter. Today, buildman --keep-outputs doesn't
actually keep the needed for booting outputs from a build for a number
of platforms. Simon's response is to stop having a free-form list of
outputs. With I guess the caveat being ROM-defined names (for example,
we still keep "MLO" because that is the literal filename TI ROM looks
for on FAT partitions, on mos of their 32bit platforms).
Why not just place the free-form files into some output/ directory and be
done with it ? Then they can have whatever extension they want, as long as
the output/ directory name is stable.
Yes, an alternative here is to just extend the list that's removed in
patch 2/6.
The ".stm32" was choosen on output on mkimage to be aligned with:
- all STMicroelectonics documentation (for example
https://wiki.st.com/stm32mpu/wiki/STM32_header_for_binary_files)
- the proposed scripts or files, in particular in the YOCTO generated
flashlayout files.
- this extension list expected by our tools: STM CubeProgrammer
(https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer)
and Signing tools (https://wiki.st.com/stm32mpu/wiki/Signing_tool)
So I prefer to kept the ".stm32" extension here:
filename = "u-boot-spl.stm32"
NB: the justification for buildman '-k' option seens not fully relevant here
because in patch 2/6 you kept not only the ALLOWED extension but
also some particular files
+to_copy = ['u-boot*', '*.map', 'MLO', 'SPL',
+ 'include/autoconf.mk', 'spl/u-boot-spl*']
+to_copy += [f'*{ext}' for ext in ALLOWED_EXTS]
so all the files "u-boot*" are kept with buildman -k even if it is not a
allowed extension.
I propose to change the patch 1/6 if you are agree
and allow binman to generate the file with same rules than buildman -k
option in patch 2/6
The filename is valid if
- the file is named with the allowed prefix 'u-boot' => 'u-boot*' so
"u-boot-spl.stm32" is allowed
- the file is with allowed extension =>.bin, .rom, .itb, .img
Regards
Patrick
Re: [PATCH 3/7] rng: stm32: Implement configurable RNG clock error detection
Hi,
On 9/8/23 21:07, Heinrich Schuchardt wrote:
On 9/7/23 18:21, Gatien Chevallier wrote:
RNG clock error detection is now enabled if the "clock-error-detect"
property is set in the device tree.
Signed-off-by: Gatien Chevallier
---
drivers/rng/stm32_rng.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index 89da78c6c8..ada5d92214 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -40,6 +40,7 @@ struct stm32_rng_plat {
struct clk clk;
struct reset_ctl rst;
const struct stm32_rng_data *data;
+ bool ced;
};
static int stm32_rng_read(struct udevice *dev, void *data, size_t len)
@@ -97,25 +98,34 @@ static int stm32_rng_init(struct stm32_rng_plat
*pdata)
cr = readl(pdata->base + RNG_CR);
- /* Disable CED */
- cr |= RNG_CR_CED;
if (pdata->data->has_cond_reset) {
cr |= RNG_CR_CONDRST;
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
writel(cr, pdata->base + RNG_CR);
cr &= ~RNG_CR_CONDRST;
+ cr |= RNG_CR_RNGEN;
writel(cr, pdata->base + RNG_CR);
err = readl_poll_timeout(pdata->base + RNG_CR, cr,
(!(cr & RNG_CR_CONDRST)), 1);
if (err)
return err;
+ } else {
+ if (pdata->ced)
+ cr &= ~RNG_CR_CED;
+ else
+ cr |= RNG_CR_CED;
+
+ cr |= RNG_CR_RNGEN;
+
+ writel(cr, pdata->base + RNG_CR);
}
/* clear error indicators */
writel(0, pdata->base + RNG_SR);
- cr |= RNG_CR_RNGEN;
- writel(cr, pdata->base + RNG_CR);
-
err = readl_poll_timeout(pdata->base + RNG_SR, sr,
sr & RNG_SR_DRDY, 1);
return err;
@@ -165,6 +175,8 @@ static int stm32_rng_of_to_plat(struct udevice *dev)
if (err)
return err;
+ pdata->ced = dev_read_bool(dev, "clock-error-detect");
The kernel describes this property in
Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
Which patch is adding it to the U-Boot device-trees?
I can't find it in this patch series.
For STM32 platform we rely on the bindin files of kernel to avoid to
duplicate the binding after yaml migration
and we add the U-Boot specificity only when it is needed (for clock and ram)
See Documentation:
https://u-boot.readthedocs.io/en/stable/board/st/st-dt.html
doc/board/st/st-dt.rst
* rng
- rng/st,stm32-rng.yaml
So for me no need of binding patch in U-Boot since [1] as this property
is already supported by kernel binding.
[1] 551a959a8c11 ("doc: stm32mp1: add page for device tree bindings")
http://patchwork.ozlabs.org/project/uboot/patch/20210802180823.1.I3aa79d907e5213c8692d2d428f5a1fbccdce555b@changeid/
Patrick
It would have been helpful to send a cover-letter with the patch series
to get an overview of the changed files in the patch set.
Best regards
Heinrich
+
return 0;
}
Re: [PATCH 1/7] rng: stm32: rename STM32 RNG driver
Hi,
On 9/7/23 18:21, Gatien Chevallier wrote:
Rename the RNG driver as it is usable by other STM32 platforms
than the STM32MP1x ones. Rename CONFIG_RNG_STM32MP1 to
CONFIG_RNG_STM32
Signed-off-by: Gatien Chevallier
---
MAINTAINERS | 2 +-
configs/stm32mp15_basic_defconfig | 2 +-
configs/stm32mp15_defconfig | 2 +-
configs/stm32mp15_trusted_defconfig | 2 +-
drivers/rng/Kconfig | 6 +++---
drivers/rng/Makefile| 2 +-
drivers/rng/{stm32mp1_rng.c => stm32_rng.c} | 0
7 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/rng/{stm32mp1_rng.c => stm32_rng.c} (100%)
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 2/7] configs: default activate CONFIG_RNG_STM32 for STM32MP13x platforms
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: Default embed this configuration. If OP-TEE PTA RNG is present as well, the priority will be given to it instead of the U-Boot driver. The STM32 RNG driver will be probed when the is activated in U-Boot device tree, it is avaiable for non secure world. OP-TEE RNG PTA will be registered when the RNG access is liited to secure world by firewall. For me not priority here but secure/non secure configuration, managed by device tree. Signed-off-by: Gatien Chevallier --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 82b62744f6..4a899c85de 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -65,6 +65,7 @@ CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_REGULATOR_SCMI=y CONFIG_RESET_SCMI=y CONFIG_DM_RNG=y +CONFIG_RNG_STM32=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y with commit message update Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 3/7] rng: stm32: Implement configurable RNG clock error detection
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: RNG clock error detection is now enabled if the "clock-error-detect" property is set in the device tree. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 4/7] rng: stm32: add RNG clock frequency restraint
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: In order to ensure a good RNG quality and compatibility with certified RNG configuration, add RNG clock frequency restraint. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 43 - 1 file changed, 38 insertions(+), 5 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 5/7] rng: stm32: add error concealment sequence
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: Seed errors can occur when using the hardware RNG. Implement the sequences to handle them. This avoids irrecoverable RNG state. Try to conceal seed errors when possible. If, despite the error concealing tries, a seed error is still present, then return an error. A clock error does not compromise the hardware block and data can still be read from RNG_DR. Just warn that the RNG clock is too slow and clear RNG_SR. Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 163 ++-- 1 file changed, 140 insertions(+), 23 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 6/7] rng: stm32: Implement custom RNG configuration support
Hi, On 9/7/23 18:21, Gatien Chevallier wrote: STM32 RNG configuration should best fit the requirements of the platform. Therefore, put a platform-specific RNG configuration field in the platform data. Default RNG configuration for STM32MP13 is the NIST certified configuration [1]. While there, fix and the RNG init sequence to support all RNG versions. [1] https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/53 Signed-off-by: Gatien Chevallier --- drivers/rng/stm32_rng.c | 54 ++--- 1 file changed, 51 insertions(+), 3 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 7/7] ARM: dts: stm32: add RNG node for STM32MP13x platforms
Hi,
On 9/7/23 18:22, Gatien Chevallier wrote:
Add RNG node for STM32MP13x platforms.
Signed-off-by: Gatien Chevallier
---
arch/arm/dts/stm32mp131.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index d23bbc3639..bd7285053d 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -1208,6 +1208,14 @@
};
};
+ rng: rng@54004000 {
+ compatible = "st,stm32mp13-rng";
+ reg = <0x54004000 0x400>;
+ clocks = <&rcc RNG1_K>;
+ resets = <&rcc RNG1_R>;
+ status = "disabled";
+ };
+
mdma: dma-controller@5800 {
compatible = "st,stm32h7-mdma";
reg = <0x5800 0x1000>;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH] configs: stm32mp*: fix system reset
Hi,
On 9/5/22 19:33, Jorge Ramirez-Ortiz wrote:
Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
from executing.
The side effect observed are I2C devices no longer being
accessible from U-boot after a soft reset.
Fixes: 11517ccc8c52 ("configs: add stm32mp13 defconfig")
Fixes: 17aeb589fa9d ("stm32mp15: remove configs dependency on
CONFIG_TFABOOT")
Signed-off-by: Jorge Ramirez-Ortiz
---
configs/stm32mp13_defconfig | 1 -
configs/stm32mp15_defconfig | 1 -
configs/stm32mp15_trusted_defconfig | 1 -
3 files changed, 3 deletions(-)
The reset driver (used to managed Hardware device reset with RCC)
based on RCC register or on SCMI for 'system' / 'secured' ressource
and the sysret for global platform based on PSCI are indendent.
Deactivate CONFIG_SYSRESET_PSCI only prevent soft reset support
with the command reset or after crash.
I don't think it is the correct solution if the I2C devices is no longer
accessible
after SW reset.
i think that it is more a bug / problem for reinit of I2C in STM32 driver
so the configuration is not correct after a SW reset.
We have not detect this issue for I2C communication to PMIC after SW reset.
Can you provide more information for your use-case, for reproduction on
my side
- platform used (STM32MP13 or STM32MP15), board used
- I2C instance used and I2C device connected
- version of TF-A / OP-TEE used
Patrick
diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig
index 673b468d31..44cee2e656 100644
--- a/configs/stm32mp13_defconfig
+++ b/configs/stm32mp13_defconfig
@@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y
CONFIG_DM_RTC=y
CONFIG_RTC_STM32=y
CONFIG_SERIAL_RX_BUFFER=y
-CONFIG_SYSRESET_PSCI=y
CONFIG_TEE=y
CONFIG_OPTEE=y
# CONFIG_OPTEE_TA_AVB is not set
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index e5a2996c2c..2ad02f3652 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -133,7 +133,6 @@ CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_STM32_SPI=y
-CONFIG_SYSRESET_PSCI=y
CONFIG_TEE=y
CONFIG_OPTEE=y
# CONFIG_OPTEE_TA_AVB is not set
diff --git a/configs/stm32mp15_trusted_defconfig
b/configs/stm32mp15_trusted_defconfig
index e14668042f..9e24e82920 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -134,7 +134,6 @@ CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_STM32_QSPI=y
CONFIG_STM32_SPI=y
-CONFIG_SYSRESET_PSCI=y
CONFIG_TEE=y
CONFIG_OPTEE=y
# CONFIG_OPTEE_TA_AVB is not set
Re: [PATCH] ARM: dts: stm32mp15: remove hwlocks from pinctrl
Hi Etienne,
On 9/5/22 11:15, Etienne Carriere wrote:
Removes hwlocks properties from stm32mp151 pinctrl node. These locks
could be used for other purpose, depending on board and software
configuration hence do not enforce their use to protect pinctrl
devices.
This patch is an alignment with Linux device tree with v6.0 as the
hwsem support wasn’t yet added in pincontrol in kernel. It avoids
issues when the Linux kernel is started with the U-Boot device tree.
Cc: Patrice Chotard
Cc: Patrick Delaunay
Signed-off-by: Etienne Carriere
---
arch/arm/dts/stm32mp151.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
index a5ac62c83d..767a06ef68 100644
--- a/arch/arm/dts/stm32mp151.dtsi
+++ b/arch/arm/dts/stm32mp151.dtsi
@@ -1663,7 +1663,6 @@
ranges = <0 0x50002000 0xa400>;
interrupt-parent = <&exti>;
st,syscfg = <&exti 0x60 0xff>;
- hwlocks = <&hwspinlock 0>;
pins-are-numbered;
gpioa: gpio@50002000 {
@@ -1796,7 +1795,6 @@
pins-are-numbered;
interrupt-parent = <&exti>;
st,syscfg = <&exti 0x60 0xff>;
- hwlocks = <&hwspinlock 0>;
gpioz: gpio@54004000 {
gpio-controller;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH v4] tee: optee: rework TA bus scanning code
Hi,
On 9/6/22 11:37, Ilias Apalodimas wrote:
Late versions of OP-TEE support a pseudo bus. TAs that behave as
hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
scan. Unfortunately U-Boot doesn't support that yet. It's worth noting
that we already have a workaround for RNG. The details are in
commit 70812bb83da6 ("tee: optee: bind rng optee driver")
So let's add a list of devices based on U-Boot Kconfig options that we will
scan until we properly implement the tee-bus functionality.
While at it change the behaviour of the tee core itself wrt to device
binding. If some device binding fails, print a warning instead of
disabling OP-TEE.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Jens Wiklander
Reviewed-by: Etienne Carriere
---
Changes since v3:
- Use NULL instead of a child ptr on device_bind_driver(), since it's not
really needed
- Changed the style of the optee_bus_probe[] definition to
{.drv_name = xxx, .dev_name = yyy }
Changes since v2:
- Fixed typo on driver name ftpm-tee -> ftpm_tee
Changes since v1:
- remove a macro and use ARRAY_SIZE directly
drivers/tee/optee/core.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
Reviewed-by: Patrick Delaunay
Thanks
Patrick
[PATCH 1/4] stm32mp: stm32prog: support empty flashlayout
When the STM32CubeProgrammer sent a empty flashlayout.tsv
file, the command stm32prog correctly parse the file
but data->dev_nb = 0 and the stm32prog_devices_init
operations should be skipped.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index c391b6c7abb..65e32288af7 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1884,6 +1884,10 @@ static void stm32prog_devices_init(struct stm32prog_data
*data)
if (ret)
goto error;
+ /* empty flashlayout */
+ if (!data->dev_nb)
+ return;
+
/* initialize the selected device */
for (i = 0; i < data->dev_nb; i++) {
ret = init_device(data, &data->dev[i]);
--
2.25.1
[PATCH 2/4] stm32mp: stm32prog: change default flashlayout location to CONFIG_SYS_LOAD_ADDR
Change the defaut flashlayout location, hardcoded at STM32_DDR_BASE,
to CONFIG_SYS_LOAD_ADDR to avoid issue on board with reserved memory
at STM32_DDR_BASE.
This patch changes the command behavior for STM32MP13 and STM32MP15
platform, as CONFIG_SYS_LOAD_ADDR(0xc200) != STM32_DDR_BASE
but without impact for serial boot with STM32CubeProgrammer.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c| 2 +-
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c| 8
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c | 2 +-
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c| 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index f59414e716f..cb9e20da136 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -61,7 +61,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, int
argc,
dev = (int)dectoul(argv[2], NULL);
- addr = STM32_DDR_BASE;
+ addr = CONFIG_SYS_LOAD_ADDR;
size = 0;
if (argc > 3) {
addr = hextoul(argv[3], NULL);
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 65e32288af7..3b2652a0e0d 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1388,7 +1388,7 @@ static int dfu_init_entities(struct stm32prog_data *data)
char buf[ALT_BUF_LEN];
sprintf(buf, "@FlashLayout/0x%02x/1*256Ke ram %x 4",
- PHASE_FLASHLAYOUT, STM32_DDR_BASE);
+ PHASE_FLASHLAYOUT, CONFIG_SYS_LOAD_ADDR);
ret = dfu_alt_add(dfu, "ram", NULL, buf);
log_debug("dfu_alt_add(ram, NULL,%s) result %d\n", buf, ret);
}
@@ -1699,15 +1699,15 @@ static void stm32prog_end_phase(struct stm32prog_data
*data, u64 offset)
{
if (data->phase == PHASE_FLASHLAYOUT) {
#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
- if (genimg_get_format((void *)STM32_DDR_BASE) ==
IMAGE_FORMAT_LEGACY) {
- data->script = STM32_DDR_BASE;
+ if (genimg_get_format((void *)CONFIG_SYS_LOAD_ADDR) ==
IMAGE_FORMAT_LEGACY) {
+ data->script = CONFIG_SYS_LOAD_ADDR;
data->phase = PHASE_END;
log_notice("U-Boot script received\n");
return;
}
#endif
log_notice("\nFlashLayout received, size = %lld\n", offset);
- if (parse_flash_layout(data, STM32_DDR_BASE, offset))
+ if (parse_flash_layout(data, CONFIG_SYS_LOAD_ADDR, offset))
stm32prog_err("Layout: invalid FlashLayout");
return;
}
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
index 2932eae7578..1bf5f5ae0ac 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_serial.c
@@ -462,7 +462,7 @@ static void get_phase_command(struct stm32prog_data *data)
length = strlen(err_msg);
}
if (phase == PHASE_FLASHLAYOUT)
- destination = STM32_DDR_BASE;
+ destination = CONFIG_SYS_LOAD_ADDR;
stm32prog_serial_putc(length + 5); /* Total length */
stm32prog_serial_putc(phase & 0xFF); /* partition ID */
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
index a8b57c4d8f0..bcb4d373f69 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
@@ -90,7 +90,7 @@ static int stm32prog_cmd_read(u64 offset, void *buf, long
*len)
}
phase = stm32prog_data->phase;
if (phase == PHASE_FLASHLAYOUT)
- destination = STM32_DDR_BASE;
+ destination = CONFIG_SYS_LOAD_ADDR;
dfu_offset = stm32prog_data->offset;
/* mandatory header, size = PHASE_MIN_SIZE */
--
2.25.1
[PATCH 4/4] stm32mp: stm32prog: correctly handle OTP when SMC is not supported
As the SMC is only supported in SP-MIN for STM32MP15x, the associated
partition should be absent when the TA NVMEM is not available in OPT-TEE
in STM32MP13x.
Signed-off-by: Patrick Delaunay
---
.../mach-stm32mp/cmd_stm32prog/stm32prog.c| 25 +--
.../mach-stm32mp/cmd_stm32prog/stm32prog.h| 5
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 67be1ac7ff8..b151ce10475 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1342,10 +1342,22 @@ static int dfu_init_entities(struct stm32prog_data
*data)
struct stm32prog_part_t *part;
struct dfu_entity *dfu;
int alt_nb;
+ u32 otp_size = 0;
alt_nb = 1; /* number of virtual = CMD*/
- if (IS_ENABLED(CONFIG_CMD_STM32PROG_OTP))
- alt_nb++; /* OTP*/
+
+ if (IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
+ /* OTP_SIZE_SMC = 0 if SMC is not supported */
+ otp_size = OTP_SIZE_SMC;
+ /* check if PTA BSEC is supported */
+ ret = optee_ta_open(data);
+ log_debug("optee_ta_open(PTA_NVMEM) result %d\n", ret);
+ if (!ret && data->tee)
+ otp_size = OTP_SIZE_TA;
+ if (otp_size)
+ alt_nb++; /* OTP*/
+ }
+
if (CONFIG_IS_ENABLED(DM_PMIC))
alt_nb++; /* PMIC NVMEM*/
@@ -1363,6 +1375,7 @@ static int dfu_init_entities(struct stm32prog_data *data)
puts("DFU alt info setting: ");
if (data->part_nb) {
alt_id = 0;
+ ret = 0;
for (phase = 1;
(phase <= PHASE_LAST_USER) &&
(alt_id < alt_nb) && !ret;
@@ -1396,12 +1409,8 @@ static int dfu_init_entities(struct stm32prog_data *data)
if (!ret)
ret = stm32prog_alt_add_virt(dfu, "virtual", PHASE_CMD,
CMD_SIZE);
- if (!ret && IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
- ret = optee_ta_open(data);
- log_debug("optee_ta result %d\n", ret);
- ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP,
-data->tee ? OTP_SIZE_TA :
OTP_SIZE_SMC);
- }
+ if (!ret && IS_ENABLED(CONFIG_CMD_STM32PROG_OTP) && otp_size)
+ ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP, otp_size);
if (!ret && CONFIG_IS_ENABLED(DM_PMIC))
ret = stm32prog_alt_add_virt(dfu, "PMIC", PHASE_PMIC,
PMIC_SIZE);
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
index 397506ac47c..58f4b96fa75 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
@@ -20,7 +20,12 @@
#define DEFAULT_ADDRESS0x
#define CMD_SIZE 512
+/* SMC is only supported in SPMIN for STM32MP15x */
+#ifdef CONFIG_STM32MP15x
#define OTP_SIZE_SMC 1024
+#else
+#define OTP_SIZE_SMC 0
+#endif
#define OTP_SIZE_TA776
#define PMIC_SIZE 8
--
2.25.1
[PATCH 3/4] stm32mp: stm32prog: solve warning for 64bits compilation
Solve many compilation warning when stm32prog is activated on the aarch64.
Signed-off-by: Patrick Delaunay
---
.../mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 14 +++---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 16
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h | 14 +++---
.../cmd_stm32prog/stm32prog_serial.c | 15 +++
.../mach-stm32mp/cmd_stm32prog/stm32prog_usb.c | 4 ++--
5 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index cb9e20da136..d2666b97757 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -126,21 +126,21 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
char *bootm_argv[5] = {
"bootm", boot_addr_start, "-", dtb_addr, NULL
};
- u32 uimage = data->uimage;
- u32 dtb = data->dtb;
- u32 initrd = data->initrd;
+ const void *uimage = (void *)data->uimage;
+ const void *dtb = (void *)data->dtb;
+ const void *initrd = (void *)data->initrd;
if (!dtb)
bootm_argv[3] = env_get("fdtcontroladdr");
else
snprintf(dtb_addr, sizeof(dtb_addr) - 1,
-"0x%x", dtb);
+"0x%p", dtb);
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
-"0x%x", uimage);
+"0x%p", uimage);
if (initrd) {
- snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%x:0x%x",
+ snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%p:0x%zx",
initrd, data->initrd_size);
bootm_argv[2] = initrd_addr;
}
@@ -148,7 +148,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
printf("Booting kernel at %s %s %s...\n\n\n",
boot_addr_start, bootm_argv[2], bootm_argv[3]);
/* Try bootm for legacy and FIT format image */
- if (genimg_get_format((void *)uimage) != IMAGE_FORMAT_INVALID)
+ if (genimg_get_format(uimage) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, 4, bootm_argv);
else if (CONFIG_IS_ENABLED(CMD_BOOTZ))
do_bootz(cmdtp, 0, 4, bootm_argv);
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 3b2652a0e0d..67be1ac7ff8 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -322,7 +322,7 @@ void stm32prog_header_check(uintptr_t raw_header, struct
image_header_s *header)
header->image_length = 0x0;
}
-static u32 stm32prog_header_checksum(u32 addr, struct image_header_s *header)
+static u32 stm32prog_header_checksum(uintptr_t addr, struct image_header_s
*header)
{
u32 i, checksum;
u8 *payload;
@@ -398,7 +398,7 @@ static int parse_name(struct stm32prog_data *data,
if (strlen(p) < sizeof(part->name)) {
strcpy(part->name, p);
} else {
- stm32prog_err("Layout line %d: partition name too long [%d]:
%s",
+ stm32prog_err("Layout line %d: partition name too long [%zd]:
%s",
i, strlen(p), p);
result = -EINVAL;
}
@@ -537,7 +537,7 @@ int (* const parse[COL_NB_STM32])(struct stm32prog_data
*data, int i, char *p,
};
static int parse_flash_layout(struct stm32prog_data *data,
- ulong addr,
+ uintptr_t addr,
ulong size)
{
int column = 0, part_nb = 0, ret;
@@ -1440,7 +1440,7 @@ int stm32prog_otp_write(struct stm32prog_data *data, u32
offset, u8 *buffer,
if (offset + *size > otp_size)
*size = otp_size - offset;
- memcpy((void *)((u32)data->otp_part + offset), buffer, *size);
+ memcpy((void *)((uintptr_t)data->otp_part + offset), buffer, *size);
return 0;
}
@@ -1479,7 +1479,7 @@ int stm32prog_otp_read(struct stm32prog_data *data, u32
offset, u8 *buffer,
data->otp_part, OTP_SIZE_TA);
else if (IS_ENABLED(CONFIG_ARM_SMCCC))
result = stm32_smc_exec(STM32_SMC_BSEC,
STM32_SMC_READ_ALL,
- (u32)data->otp_part, 0);
+
[PATCH] ARM: dts: stm32mp: alignment with v6.0-rc3
Device tree alignment with Linux kernel v6.0-rc3:
- ARM: dts: stm32: add support for USB2514B onboard hub on stm32mp15xx-dkx
- ARM: dts: stm32: Add alternate pinmux for RCC pin
- ARM: dts: stm32: Add alternate pinmux for DCMI pins
- ARM: dts: stm32: Add alternate pinmux for SPI2 pins
- ARM: dts: stm32: Fix SPI2 pinmux pin comments on stm32mp15
- ARM: dts: stm32: add optee reserved memory on stm32mp135f-dk
- ARM: dts: stm32: enable optee firmware and SCMI support on STM32MP13
- ARM: dts: stm32: remove the IPCC "wakeup" IRQ on stm32mp151
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp13-u-boot.dtsi | 10 +++--
arch/arm/dts/stm32mp131.dtsi| 28 ++---
arch/arm/dts/stm32mp135f-dk.dts | 4 +-
arch/arm/dts/stm32mp15-pinctrl.dtsi | 64 ++---
arch/arm/dts/stm32mp151.dtsi| 7 ++--
arch/arm/dts/stm32mp15xx-dkx.dtsi | 8
6 files changed, 91 insertions(+), 30 deletions(-)
diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
b/arch/arm/dts/stm32mp13-u-boot.dtsi
index 01552adb7c4..47a43649bbb 100644
--- a/arch/arm/dts/stm32mp13-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
@@ -17,6 +17,12 @@
pinctrl0 = &pinctrl;
};
+ firmware {
+ optee {
+ u-boot,dm-pre-reloc;
+ };
+ };
+
/* need PSCI for sysreset during board_f */
psci {
u-boot,dm-pre-proper;
@@ -82,10 +88,6 @@
u-boot,dm-pre-reloc;
};
-&optee {
- u-boot,dm-pre-reloc;
-};
-
&pinctrl {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index 84e16bb2f2b..a1c6d0d00b5 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -27,21 +27,8 @@
interrupt-parent = <&intc>;
};
- scmi_sram: sram@2000 {
- compatible = "mmio-sram";
- reg = <0x2000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x2000 0x1000>;
-
- scmi_shm: scmi_shm@0 {
- compatible = "arm,scmi-shmem";
- reg = <0 0x80>;
- };
- };
-
firmware {
- optee: optee {
+ optee {
method = "smc";
compatible = "linaro,optee-tz";
};
@@ -151,6 +138,19 @@
interrupt-parent = <&intc>;
ranges;
+ scmi_sram: sram@2000 {
+ compatible = "mmio-sram";
+ reg = <0x2000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x2000 0x1000>;
+
+ scmi_shm: scmi-sram@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0 0x80>;
+ };
+ };
+
uart4: serial@4001 {
compatible = "st,stm32h7-uart";
reg = <0x4001 0x400>;
diff --git a/arch/arm/dts/stm32mp135f-dk.dts b/arch/arm/dts/stm32mp135f-dk.dts
index f436ffab998..e6b8ffd332c 100644
--- a/arch/arm/dts/stm32mp135f-dk.dts
+++ b/arch/arm/dts/stm32mp135f-dk.dts
@@ -31,8 +31,8 @@
#size-cells = <1>;
ranges;
- optee@de00 {
- reg = <0xde00 0x200>;
+ optee@dd00 {
+ reg = <0xdd00 0x300>;
no-map;
};
};
diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/dts/stm32mp15-pinctrl.dtsi
index d3ed10335df..2cc9341d43d 100644
--- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
@@ -151,6 +151,43 @@
};
};
+ dcmi_pins_c: dcmi-2 {
+ pins {
+ pinmux = ,/* DCMI_HSYNC */
+,/* DCMI_VSYNC */
+,/* DCMI_PIXCLK */
+,/* DCMI_D0 */
+,/* DCMI_D1 */
+,/* DCMI_D2 */
+,/* DCMI_D3 */
+,/* DCMI_D4 */
+,/* DCMI_D5 */
+,/* DCMI_D6 */
+,/* DCMI_D7 */
+,/* DCMI_D8 */
+;/* DCMI_D9 */
+ bias-pull-up;
+ };
+ };
+
+ dcmi_sleep_pins_c: dcmi-sleep-2 {
+ pins {
+
Re: [PATCH] stm32mp: simplify the STM32MP15x package parsing code
Hi, On 6/20/22 09:50, Patrick Delaunay wrote: Simplify the package parsing code for STM32MP15X as package can be affected with get_cpu_package() result. Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/stm32mp15x.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH] board: stm32mp1: remove test on CONFIG_DM_REGULATOR
Hi,
On 6/20/22 12:36, Patrick Delaunay wrote:
The tests on CONFIG_DM_REGULATOR, added to avoid compilation issues, can
now be removed, they are no more needed since the commit 16cc5ad0b439
("power: regulator: add dummy helper").
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
Applied to u-boot-stm/master, thanks!
Regards
Patrick
Re: [PATCH 1/3] phy: stm32-usbphyc: add counter of PLL consumer
Hi, On 4/26/22 14:37, Patrick Delaunay wrote: Add the counter of the PLL user n_pll_cons managed by the 2 functions stm32_usbphyc_pll_enable / stm32_usbphyc_pll_disable. This counter allow to remove the function stm32_usbphyc_is_init and it is a preliminary step for ck_usbo_48m introduction. Signed-off-by: Patrick Delaunay --- drivers/phy/phy-stm32-usbphyc.c | 76 + 1 file changed, 48 insertions(+), 28 deletions(-) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH 2/3] phy: stm32-usbphyc: usbphyc is a clock provider of ck_usbo_48m clock
Hi, On 4/26/22 14:37, Patrick Delaunay wrote: ck_usbo_48m is generated by usbphyc PLL and used by OTG controller for Full-Speed use cases with dedicated Full-Speed transceiver. ck_usbo_48m is available as soon as the PLL is enabled. Signed-off-by: Patrick Delaunay --- drivers/phy/phy-stm32-usbphyc.c | 79 + 1 file changed, 79 insertions(+) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH 3/3] clk: stm32mp: handle ck_usbo_48m clock provided by USBPHYC
Hi, On 4/26/22 14:37, Patrick Delaunay wrote: Handle the input clock of RCC USB_PHY_48, provided by USBPHYC and named "ck_usbo_48m". Signed-off-by: Patrick Delaunay --- drivers/clk/clk_stm32mp1.c | 35 --- 1 file changed, 20 insertions(+), 15 deletions(-) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH] ARM: dts: stm32: Fix display-timings settings for stm32f746-disco
Hi, On 8/24/22 15:42, Patrice Chotard wrote: Since commit ef4ce6df3289 "video: stm32: stm32_ltdc: fix data enable polarity" The panel display output wasn't functional anymore. Device tree display-timings de-active property value must be updated to 1. Signed-off-by: Patrice Chotard --- arch/arm/dts/stm32f746-disco-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH] configs: stm32: Enable CONFIG_DM_REGULATOR for stm32f769-disco
Hi,
On 8/24/22 15:44, Patrice Chotard wrote:
Since commit 5bc6f8c2a97e("video: stm32: remove test on CONFIG_DM_REGULATOR")
backlight was broken with the following message at boot:
stm32-display-dsi dsi@40016c00: Warning: cannot get phy dsi supply
stm32_display display-controller@40016800: panel panel enable backlight error
-38
DM_REGULATOR flag must be enabled to fix this issue
Signed-off-by: Patrice Chotard
---
configs/stm32f769-disco_defconfig | 1 +
configs/stm32f769-disco_spl_defconfig | 1 +
2 files changed, 2 insertions(+)
Applied to u-boot-stm/master, thanks!
Regards
Patrick
Re: [PATCH v2] configs: stih410-b2260: Fix SYS_HZ_CLOCK value
Hi, On 8/25/22 09:14, Patrice Chotard wrote: SYS_HZ_CLOCK was wrongly set to 1GHz whereas it's set to 750MHz by default by bootrom. Signed-off-by: Patrice Chotard Reviewed-by: Grzegorz Szymaszek --- Changes in v2: - Replace 1MHz by 1GHz in commit description include/configs/stih410-b2260.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/stih410-b2260.h b/include/configs/stih410-b2260.h index b1a011bacb..1e966a2322 100644 --- a/include/configs/stih410-b2260.h +++ b/include/configs/stih410-b2260.h @@ -14,7 +14,7 @@ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 #define PHYS_SDRAM_1_SIZE 0x3E00 -#define CONFIG_SYS_HZ_CLOCK 10 /* 1 GHz */ +#define CONFIG_SYS_HZ_CLOCK75000 /* 750 MHz */ /* Environment */ Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH] ARM: stm32: Switch DHSOM to FMC2 EBI driver
Hi, On 8/23/22 19:27, Marek Vasut wrote: Perform long overdue conversion of ad-hoc FMC2 EBI bus initialization to upstream FMC2 EBI driver. No functional change. Signed-off-by: Marek Vasut Cc: Patrice Chotard Cc: Patrick Delaunay --- .../dts/stm32mp15xx-dhcom-picoitx-u-boot.dtsi | 8 --- arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi| 14 - .../stm32mp15xx-dhcor-drc-compact-u-boot.dtsi | 16 -- board/dhelectronics/dh_stm32mp1/board.c | 52 --- configs/stm32mp15_dhcom_basic_defconfig | 1 + configs/stm32mp15_dhcor_basic_defconfig | 1 + 6 files changed, 2 insertions(+), 90 deletions(-) Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH] ARM: dts: stm32mp15: remove hwlocks from pinctrl
Hi, On 9/5/22 11:15, Etienne Carriere wrote: Removes hwlocks properties from stm32mp151 pinctrl node. These locks could be used for other purpose, depending on board and software configuration hence do not enforce their use to protect pinctrl devices. This patch is an alignment with Linux device tree with v6.0 as the hwsem support wasn’t yet added in pincontrol in kernel. It avoids issues when the Linux kernel is started with the U-Boot device tree. Cc: Patrice Chotard Cc: Patrick Delaunay Signed-off-by: Etienne Carriere --- arch/arm/dts/stm32mp151.dtsi | 2 -- 1 file changed, 2 deletions(-) Applied to u-boot-stm/master, thanks! Regards Patrick
[PATCH] confis: stm32mp15: activate DM_REGULATOR_SCMI
Activate the support of SCMI regulator to support the scmi_reg11,
scmi_reg18 and scmi_usb33 regulators present in the scmi device tree of
STMicroelectronics boards with stm32mp15-scmi.dtsi
Fixes: 68d396bf ("ARM: dts: stm32: add SCMI version of STM32 boards
(DK1/DK2/ED1/EV1)")
Signed-off-by: Patrick Delaunay
---
configs/stm32mp15_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index fd2a5de8d13..0f6b3738cad 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -120,6 +120,7 @@ CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_DM_REGULATOR_STM32_VREFBUF=y
CONFIG_DM_REGULATOR_STPMIC1=y
+CONFIG_DM_REGULATOR_SCMI=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
--
2.25.1
[PULL] Pull request for u-boot master / v2022.10 = u-boot-stm32-20220907
Hi Tom, Please pull the STM32 related fixes for u-boot/master, v2022.10: u-boot-stm32-20220907 - simplify the STM32MP15x package parsing code - remove test on CONFIG_DM_REGULATOR in stm32mp1 board and enable CONFIG_DM_REGULATOR for stm32f769-disco - handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start' after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>) - Fix SYS_HZ_CLOCK value for stih410-b2260 board - Switch STMM32MP15x DHSOM to FMC2 EBI driver - Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/13383 Thanks, Patrick git request-pull origin/master https://source.denx.de/u-boot/custodians/u-boot-stm.git/ u-boot-stm32-20220907 The following changes since commit 51601397fcbb13e6dc2e4223408230c82955a601: Prepare v2022.10-rc4 (2022-09-05 20:32:56 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git/ tags/u-boot-stm32-20220907 for you to fetch changes up to d6ff3c9f04f744345fe77a3d82c5b5e0c07c456a: ARM: dts: stm32mp15: remove hwlocks from pinctrl (2022-09-06 15:40:14 +0200) - simplify the STM32MP15x package parsing code - remove test on CONFIG_DM_REGULATOR in stm32mp1 board and enable CONFIG_DM_REGULATOR for stm32f769-disco - handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start' after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>) - Fix SYS_HZ_CLOCK value for stih410-b2260 board - Switch STMM32MP15x DHSOM to FMC2 EBI driver - Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel Etienne Carriere (1): ARM: dts: stm32mp15: remove hwlocks from pinctrl Marek Vasut (1): ARM: stm32: Switch DHSOM to FMC2 EBI driver Patrice Chotard (3): ARM: dts: stm32: Fix display-timings settings for stm32f746-disco configs: stm32: Enable CONFIG_DM_REGULATOR for stm32f769-disco configs: stih410-b2260: Fix SYS_HZ_CLOCK value Patrick Delaunay (5): stm32mp: simplify the STM32MP15x package parsing code board: stm32mp1: remove test on CONFIG_DM_REGULATOR phy: stm32-usbphyc: add counter of PLL consumer phy: stm32-usbphyc: usbphyc is a clock provider of ck_usbo_48m clock clk: stm32mp: handle ck_usbo_48m clock provided by USBPHYC arch/arm/dts/stm32f746-disco-u-boot.dtsi | 2 +- arch/arm/dts/stm32mp151.dtsi | 2 -- arch/arm/dts/stm32mp15xx-dhcom-picoitx-u-boot.dtsi | 8 - arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 14 - arch/arm/dts/stm32mp15xx-dhcor-drc-compact-u-boot.dtsi | 16 -- arch/arm/mach-stm32mp/stm32mp15x.c | 15 ++ board/dhelectronics/dh_stm32mp1/board.c | 52 board/st/stm32mp1/stm32mp1.c | 8 ++--- configs/stm32f769-disco_defconfig | 1 + configs/stm32f769-disco_spl_defconfig | 1 + configs/stm32mp15_dhcom_basic_defconfig | 1 + configs/stm32mp15_dhcor_basic_defconfig | 1 + drivers/clk/stm32/clk-stm32mp1.c | 35 -- drivers/phy/phy-stm32-usbphyc.c | 155 +- include/configs/stih410-b2260.h | 2 +- 15 files changed, 158 insertions(+), 155 deletions(-)
Re: [PATCH 2/2] usb: hub: increase HUB_DEBOUNCE_TIMEOUT
Hi Marek,
On 7/8/22 17:34, Marek Vasut wrote:
On 7/4/22 12:45, Patrick Delaunay wrote:
Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb device
needs around 1.5s or more to make the hub port status to be
connected steadily after being powered off and powered on.
These value is aligned with Linux driver and avoids to configure
"usb_pgood_delay" as a workaround for connection timeout on
some USB device; normally the env variable "usb_pgood_delay" is used
to delay the first query after power ON and thus the device answer,
but this variable not to increase the connection timeout delay.
Signed-off-by: Patrick Delaunay
---
Hi,
I think this patch solves a general issue because a 1s timeout for
USB connection is too short on problematic USB keys / USB HUB.
The issue was introduced by the commit c998da0d6709 ("usb: Change
power-on / scanning timeout handling")
Patching usb_hub allows to avoid to patch in each board/driver.
For example, commit 0417169054cb ("imx: ventana: add usb_pgood_delay
2sec default") => use pgood_delay = 2s !?
or ("ARM: stm32: Increase USB power-good delay on DHSOM")
https://patchwork.ozlabs.org/project/uboot/patch/2023022444.231801-1-ma...@denx.de/
or commit 2bf352f0c1b7 ("usb: dwc2: Add delay to fix the USB
detection problem on SoCFPGA") => patch in USB DWC2 driver to add
a timeout in driver
The commit 319418c01c95 ("usb: hub: allow pgood_delay to be
specified via env") introduces an env variable for warm-up times
managed by hub->query_delay.
But it is not linked to the connect timeout after power on
managed by hub->connect_timeout.
This patch can increase the boot time for some board when USB device is
not available; if it is a problem I can introduce a new config:
CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to define this value with default = 1s
to keep the current behavior.
This issue appears with DWC2 and USB HUB used in STM32MP135F-DK board;
pgood_delay=2 is not enough to solved all the USB key detection issues.
Patrick
common/usb_hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index d73638950b9..e681f1b3073 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -47,7 +47,7 @@
#define HUB_SHORT_RESET_TIME 20
#define HUB_LONG_RESET_TIME 200
-#define HUB_DEBOUNCE_TIMEOUT 1000
+#define HUB_DEBOUNCE_TIMEOUT 2000
Do you think it is possible to make this somehow dynamic , so not all
devices would wait so long ?
Yes I do it in V2.
Patrick
Re: [PATCH 1/3] i2c: stm32: fix comment and remove unused AUTOEND bit
Hi,
On 9/8/22 10:06, Alain Volmat wrote:
Comment within stm32_i2c_message_start is misleading, indicating
that AUTOEND bit is setted while it is actually cleared.
Moreover, the bit is actually never setted so there is no need
to clear it hence get rid of this bit clear and the bit macro
as well.
Signed-off-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..78d7156492 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -57,7 +57,6 @@ struct stm32_i2c_regs {
#define STM32_I2C_CR1_PE BIT(0)
/* STM32 I2C control 2 */
-#define STM32_I2C_CR2_AUTOEND BIT(25)
#define STM32_I2C_CR2_RELOAD BIT(24)
#define STM32_I2C_CR2_NBYTES_MASK GENMASK(23, 16)
#define STM32_I2C_CR2_NBYTES(n) ((n & 0xff) << 16)
@@ -304,9 +303,8 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
cr2 |= STM32_I2C_CR2_SADD7(msg->addr);
}
- /* Set nb bytes to transfer and reload or autoend bits */
- cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD |
-STM32_I2C_CR2_AUTOEND);
+ /* Set nb bytes to transfer and reload (if needed) */
+ cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD);
if (msg->len > STM32_I2C_MAX_LEN) {
cr2 |= STM32_I2C_CR2_NBYTES(STM32_I2C_MAX_LEN);
cr2 |= STM32_I2C_CR2_RELOAD;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH 2/3] i2c: stm32: remove unused stop parameter in start & reload handling
Hi
On 9/8/22 10:06, Alain Volmat wrote:
Functions stm32_i2c_message_start and stm32_i2c_handle_reload
both get a stop boolean indicating if the transfer should end with
a STOP or not. However no specific handling is needed in those
functions hence remove the parameter.
Signed-off-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 78d7156492..0ec67b5c12 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -282,7 +282,7 @@ static int stm32_i2c_check_device_busy(struct
stm32_i2c_priv *i2c_priv)
}
static void stm32_i2c_message_start(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -325,7 +325,7 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
*/
static void stm32_i2c_handle_reload(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -431,7 +431,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
/* Add errors */
mask |= STM32_I2C_ISR_ERRORS;
- stm32_i2c_message_start(i2c_priv, msg, stop);
+ stm32_i2c_message_start(i2c_priv, msg);
while (msg->len) {
/*
@@ -469,7 +469,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
mask = msg->flags & I2C_M_RD ? STM32_I2C_ISR_RXNE :
STM32_I2C_ISR_TXIS | STM32_I2C_ISR_NACKF;
- stm32_i2c_handle_reload(i2c_priv, msg, stop);
+ stm32_i2c_handle_reload(i2c_priv, msg);
} else if (!bytes_to_rw) {
/* Wait until TC flag is set */
mask = STM32_I2C_ISR_TC;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH v2 1/3] i2c: stm32: fix comment and remove unused AUTOEND bit
Hi,
On 9/8/22 12:59, Alain Volmat wrote:
Comment within stm32_i2c_message_start is misleading, indicating
that AUTOEND bit is setted while it is actually cleared.
Moreover, the bit is actually never setted so there is no need
to clear it hence get rid of this bit clear and the bit macro
as well.
Signed-off-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..78d7156492 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -57,7 +57,6 @@ struct stm32_i2c_regs {
#define STM32_I2C_CR1_PE BIT(0)
/* STM32 I2C control 2 */
-#define STM32_I2C_CR2_AUTOEND BIT(25)
#define STM32_I2C_CR2_RELOAD BIT(24)
#define STM32_I2C_CR2_NBYTES_MASK GENMASK(23, 16)
#define STM32_I2C_CR2_NBYTES(n) ((n & 0xff) << 16)
@@ -304,9 +303,8 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
cr2 |= STM32_I2C_CR2_SADD7(msg->addr);
}
- /* Set nb bytes to transfer and reload or autoend bits */
- cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD |
-STM32_I2C_CR2_AUTOEND);
+ /* Set nb bytes to transfer and reload (if needed) */
+ cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD);
if (msg->len > STM32_I2C_MAX_LEN) {
cr2 |= STM32_I2C_CR2_NBYTES(STM32_I2C_MAX_LEN);
cr2 |= STM32_I2C_CR2_RELOAD;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH v2 2/3] i2c: stm32: remove unused stop parameter in start & reload handling
Hi,
On 9/8/22 12:59, Alain Volmat wrote:
Functions stm32_i2c_message_start and stm32_i2c_handle_reload
both get a stop boolean indicating if the transfer should end with
a STOP or not. However no specific handling is needed in those
functions hence remove the parameter.
Signed-off-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 78d7156492..0ec67b5c12 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -282,7 +282,7 @@ static int stm32_i2c_check_device_busy(struct
stm32_i2c_priv *i2c_priv)
}
static void stm32_i2c_message_start(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -325,7 +325,7 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
*/
static void stm32_i2c_handle_reload(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -431,7 +431,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
/* Add errors */
mask |= STM32_I2C_ISR_ERRORS;
- stm32_i2c_message_start(i2c_priv, msg, stop);
+ stm32_i2c_message_start(i2c_priv, msg);
while (msg->len) {
/*
@@ -469,7 +469,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
mask = msg->flags & I2C_M_RD ? STM32_I2C_ISR_RXNE :
STM32_I2C_ISR_TXIS | STM32_I2C_ISR_NACKF;
- stm32_i2c_handle_reload(i2c_priv, msg, stop);
+ stm32_i2c_handle_reload(i2c_priv, msg);
} else if (!bytes_to_rw) {
/* Wait until TC flag is set */
mask = STM32_I2C_ISR_TC;
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Re: [PATCH v2 3/3] i2c: stm32: only send a STOP upon transfer completion
Hi, On 9/8/22 12:59, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. This can be especially seen when the processing get slower (ex: enabling lots of debug messages), ending up send 2 STOP (one automatically by the controller and a 2nd one at the end of the stm32_i2c_message_xfer function). Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..8803979d3e 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -477,16 +477,16 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, if (ret) break; + /* End of transfer, send stop condition */ + mask = STM32_I2C_CR2_STOP; + setbits_le32(®s->cr2, mask); + if (!stop) /* Message sent, new message has to be sent */ return 0; } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); - return stm32_i2c_check_end_of_message(i2c_priv); } Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] configs: stm32mp*: fix system reset
Hi,
On 9/6/22 16:53, Jorge Ramirez-Ortiz, Foundries wrote:
On 06/09/22, Patrick DELAUNAY wrote:
Hi,
On 9/5/22 19:33, Jorge Ramirez-Ortiz wrote:
Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI
from executing.
The side effect observed are I2C devices no longer being
accessible from U-boot after a soft reset.
Fixes: 11517ccc8c52 ("configs: add stm32mp13 defconfig")
Fixes: 17aeb589fa9d ("stm32mp15: remove configs dependency on
CONFIG_TFABOOT")
Signed-off-by: Jorge Ramirez-Ortiz
---
configs/stm32mp13_defconfig | 1 -
configs/stm32mp15_defconfig | 1 -
configs/stm32mp15_trusted_defconfig | 1 -
3 files changed, 3 deletions(-)
The reset driver (used to managed Hardware device reset with RCC)
based on RCC register or on SCMI for 'system' / 'secured' ressource
and the sysret for global platform based on PSCI are indendent.
Yes. But AFAICS in the trace only one executes during the sys reset walk and
PSCI gets in first (so SCMI doesnt run when U-boot reboots).
For my understanding the STM32MP15 Linux Kernel also use
PSCI for reset (for command reboot)
drivers/firmware/psci/psci.c::psci_sys_reset
ref: https://wiki.st.com/stm32mpu/wiki/Power_overview
You should have also the issue with reboot command in Linux...
And for SCMI device tree or downstream the PSCI is the only support
SYSRESET driver supported (SYSCON on RCC not available on secured
device and I don't known SCMI sysreset driver in U-Boot)
We have also STPMIC1 sysreset support by only when the PMIC is managed
by U-Boot
(present in U-Boot device DT, not secured).
STM32MP> dm tree
Class Index Probed Driver Name
---
root 0 [ + ] root_driver root_driver
firmware 0 [ ] psci |-- psci
sysreset 0 [ ] psci-sysreset | `-- psci-sysreset
i2c 1 [ + ] stm32f7-i2c | |-- i2c@5c002000
i2c_generi 0 [ ] stusb160x | | |-- stusb1600@28
pmic 0 [ + ] stpmic1_pmic | | `-- stpmic@33
...
misc 0 [ ] stpmic1-nvm | | |-- stpmic1-nvm
sysreset 1 [ ] stpmic1-sysreset | | `--
stpmic1-sysreset
For me, the PSCI can be used in the sysreset_walk() without issue on I2C
devices
managed in secure world or in non secure world
(tested on STMicroelectronics boards with several I2C device
= STPMIC, STUSB1600, STMFX, touchscreen, panel...).
But we don't test I2C device used by booth worlds.
Deactivate CONFIG_SYSRESET_PSCI only prevent soft reset support
with the command reset or after crash.
Also AFAICS, the kernel only uses SCMI for reset (which probably explains why
OP-TEE controlled I2C devices still work when the board reboots).
I don't think it is the correct solution if the I2C devices is no longer
accessible
after SW reset.
i think that it is more a bug / problem for reinit of I2C in STM32 driver
so the configuration is not correct after a SW reset.
Not sure about that...but lets find out because something is wrong for sure.
We have not detect this issue for I2C communication to PMIC after SW reset.
that could be because the PMIC uses the only I2C mode that works with
OP-TEE (the master transfer mode is broken until my fixes are merged...hopefully
soon)
Can you provide more information for your use-case, for reproduction on my
side
- platform used (STM32MP13 or STM32MP15), board used
STM32MP15
- I2C instance used and I2C device connected
NXPSE050 - i2c in master xfer mode, accessible only from OP-TEE
https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf
So in your use-case, if I correctly understood
1/ I2C accesses in OP-TEE to NXPSE050 in secure world = OP-TEE I2C driver
2/ jump to normal world during boot = U-Boot
3/ I2C accesses in U-Boot (or kernel ?) to NXPSE050 in normal world =>
U-Boot I2C driver
4/ <<< reset request in U-Boot !? >>>
a) when PSCI sysreset is used (without your patch)
=> PSCI stack manage in OP-TEE request system reset
=> psci_system_reset()
=> io_write32(rcc_base + RCC_MP_GRSTCSETR,
RCC_MP_GRSTCSETR_MPSYSRST);
=> OP-TEE I2C driver failed after reboot !?
it is the problem
b) when an other sysreset is used, STPMIC1 ?
=> OP-TEE I2C driver ok after reboot
I assumed that here that STPMIC1 is used, it is the only
other sysreset supported
so it is a cold boot has the STM32MP15x supply is shut-down
so my analysis:
you have a I2C issue when the same I2C instance is used in OP-TEE
and in normal world
after a application / system reset generated by
RCC_MP_GRSTCSETR.MPSYSRST
the I2C bus that you are using for NXPSE050 is not correctly
re-initialized and
Re: [PATCHv2 2/2] i2c: stm32f7: do not set the STOP condition on error
Hi, On 9/7/22 11:20, Alain Volmat wrote: Hi, I confirm that a fix is necessary regarding this setting of the stop condition. As a matter of fact, the controller is already sending the stop condition in case of NACK so there is no need to send the stop condition. However, this fix is not enough since the nack could be detected few lines above if (status & (STM32_I2C_ISR_NACKF | STM32_I2C_ISR_ERRORS)) break; and in this case the current check would not catch it. I propose to set the STOP condition upon handling of the transfer complete. I've put this fix within a small 3 patches series that I'm going to send, could you check it to confirm this fixes the issue ? Regards, Alain On Thu, Aug 25, 2022 at 03:36:36PM +0200, Patrice CHOTARD wrote: +Alain (with the correct email address ;-)) Alain, can you have a look a this patch and give your feedback on it. On my side i tested it on stm32mp157c-ev1 and stm32mp157c-dk2, i didn't see any regression but i prefer to get expert feedback Thanks Patrice On 8/15/22 16:52, Jorge Ramirez-Ortiz wrote: Sending the stop condition without waiting for transfer complete has been found to lock the bus (BUSY) when NACKF is raised. Tested accessing the NXP SE05X I2C device. https://www.nxp.com/docs/en/application-note/AN12399.pdf Signed-off-by: Jorge Ramirez-Ortiz Reviewed-by: Oleksandr Suvorov --- drivers/i2c/stm32f7_i2c.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) For reference, this patch is superseded by Alain Volmat patch: [v2,1/3] i2c: stm32: fix comment and remove unused AUTOEND bit http://patchwork.ozlabs.org/project/uboot/patch/20220908105934.1764482-2-alain.vol...@foss.st.com/ in the serie "i2c: stm32: cleanup & stop handling fix" http://patchwork.ozlabs.org/project/uboot/list/?series=317443&state=* Regards Patrick
[PATCH v2 2/2] configs: stm32mp15: set CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=2s
With some USB devices connected on USB HUB for the STMicroelectronics boards, set the usb_pgood_delay=2 is not enough to ensure a correct detection for all cases; but it is solved with USB_HUB_DEBOUNCE_TIMEOUT=2s. For example, issue encountered with the USB flash disk: ID 058f:6387 Alcor Micro Corp. Flash Drive Signed-off-by: Patrick Delaunay --- Changes in v2: - force CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=2s for stm32mp15 defconfig configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 33680dc25e9..efb506c1172 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -46,6 +46,7 @@ CONFIG_SPL_POWER=y CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 CONFIG_FDT_SIMPLEFB=y +CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=2000 CONFIG_SYS_PBSIZE=1050 CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_ADTIMG=y diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index fd2a5de8d13..ba87b511974 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -22,6 +22,7 @@ CONFIG_FIT=y CONFIG_BOOTDELAY=1 CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" CONFIG_FDT_SIMPLEFB=y +CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=2000 CONFIG_SYS_PBSIZE=1050 CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_ADTIMG=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 1154eec210c..6644ea4c81f 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -23,6 +23,7 @@ CONFIG_FIT=y CONFIG_BOOTDELAY=1 CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" CONFIG_FDT_SIMPLEFB=y +CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=2000 CONFIG_SYS_PBSIZE=1050 CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_ADTIMG=y -- 2.25.1
[PATCH v2 1/2] usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT
Add a new CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to increase the
HUB_DEBOUNCE_TIMEOUT value, for example to 2s because some usb device
needs around 1.5s or more to make the hub port status to be
connected steadily after being powered off and powered on.
This 2s value is aligned with Linux driver and avoids to configure
"usb_pgood_delay" as a workaround for connection timeout on
some USB device; normally the env variable "usb_pgood_delay" is used
to delay the first query after power ON and thus the device answer,
but this variable not used to increase the connection timeout delay.
Signed-off-by: Patrick Delaunay
---
Hi,
V2 of previous patch [1] after Marek request to a add a CONFIG_.
I think this patch solves a general issue because a 1s timeout for
USB connection is too short on problematic USB keys / USB HUB.
The issue was introduced by the commit c998da0d6709 ("usb: Change
power-on / scanning timeout handling")
Patching usb_hub allows to avoid to patch in each board/driver.
For example, commit 0417169054cb ("imx: ventana: add usb_pgood_delay
2sec default") => use pgood_delay = 2s !?
or ("ARM: stm32: Increase USB power-good delay on DHSOM")
https://patchwork.ozlabs.org/project/uboot/patch/2023022444.231801-1-ma...@denx.de/
or commit 2bf352f0c1b7 ("usb: dwc2: Add delay to fix the USB
detection problem on SoCFPGA") => patch in USB DWC2 driver to add
a timeout in driver
The commit 319418c01c95 ("usb: hub: allow pgood_delay to be
specified via env") introduces an env variable for warm-up times
managed by hub->query_delay.
But it is not linked to the connect timeout after power on
managed by hub->connect_timeout.
This patch allow to increase the boot time for some board when USB device
is not available; the default value = 1s of the config
CONFIG_USB_HUB_DEBOUNCE_TIMEOUT allow to keep the current behavior.
This issue appears with DWC2 and USB HUB used in STM32MP135F-DK board;
pgood_delay=2 is not enough to solved all the USB key detection issues.
[1] [2/2] usb: hub: increase HUB_DEBOUNCE_TIMEOUT
http://patchwork.ozlabs.org/project/uboot/patch/20220704124540.2.I5eabf3f9fdbbaf763cd44e9c018cb5b74a0c65ac@changeid/
Patrick
Changes in v2:
- allow defconfig configuration by CONFIG_USB_HUB_DEBOUNCE_TIMEOUT
common/Kconfig | 12
common/usb_hub.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig b/common/Kconfig
index e7914ca750a..fedb643ea58 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -992,3 +992,15 @@ config FDT_SIMPLEFB
These functions can be used by board to indicate to the OS
the presence of the simple frame buffer with associated reserved
memory
+
+config USB_HUB_DEBOUNCE_TIMEOUT
+ int "Timeout in milliseconds for USB HUB connection"
+ depends on USB
+ default 1000
+ help
+ Value in milliseconds of the USB connection timeout, the max delay to
+ wait the hub port status to be connected steadily after being powered
+ off and powered on in the usb hub driver.
+ This define allows to increase the HUB_DEBOUNCE_TIMEOUT default
+ value = 1s because some usb device needs around 1.5s to be initialized
+ and a 2s value should solve detection issue on problematic USB keys.
diff --git a/common/usb_hub.c b/common/usb_hub.c
index d73638950b9..87fd93c55db 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -47,7 +47,7 @@
#define HUB_SHORT_RESET_TIME 20
#define HUB_LONG_RESET_TIME200
-#define HUB_DEBOUNCE_TIMEOUT 1000
+#define HUB_DEBOUNCE_TIMEOUT CONFIG_USB_HUB_DEBOUNCE_TIMEOUT
#define PORT_OVERCURRENT_MAX_SCAN_COUNT3
--
2.25.1
Re: [PATCH v2 3/3] i2c: stm32: only send a STOP upon transfer completion
Hi, On 9/9/22 10:43, Heiko Schocher wrote: Hello Jorge, On 09.09.22 10:30, Jorge Ramirez-Ortiz, Foundries wrote: On 08/09/22, Patrick DELAUNAY wrote: Hi, On 9/8/22 12:59, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. This can be especially seen when the processing get slower (ex: enabling lots of debug messages), ending up send 2 STOP (one automatically by the controller and a 2nd one at the end of the stm32_i2c_message_xfer function). Cmon no need to thank me, that is kind of excessive :) Just the sign-off or codevelop tags for reference if you can wait before merging I will test the series before monday I would love to see a test before we merge this. @Patrick: feel free to merge it through stm32 repo. Ok, I will take this serie in my next pull request for stm32 Thanks! bye, Heiko By Patrick thanks Jorge Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..8803979d3e 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -477,16 +477,16 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, if (ret) break; + /* End of transfer, send stop condition */ + mask = STM32_I2C_CR2_STOP; + setbits_le32(®s->cr2, mask); + if (!stop) /* Message sent, new message has to be sent */ return 0; } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); - return stm32_i2c_check_end_of_message(i2c_priv); } Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH v2 3/3] i2c: stm32: only send a STOP upon transfer completion
Hi Alain On 9/8/22 12:59, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. This can be especially seen when the processing get slower (ex: enabling lots of debug messages), ending up send 2 STOP (one automatically by the controller and a 2nd one at the end of the stm32_i2c_message_xfer function). Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..8803979d3e 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -477,16 +477,16 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, if (ret) break; + /* End of transfer, send stop condition */ + mask = STM32_I2C_CR2_STOP; + setbits_le32(®s->cr2, mask); + if (!stop) /* Message sent, new message has to be sent */ return 0; } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); - return stm32_i2c_check_end_of_message(i2c_priv); } Boot on DK2 failed with the traces: U-Boot 2022.10-rc4-00043-g5b118161055 (Sep 09 2022 - 14:19:12 +0200) CPU: STM32MP157CAC Rev.B Model: STMicroelectronics STM32MP157C-DK2 Discovery Board Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2) Board: MB1272 Var2.0 Rev.C-01 DRAM: 512 MiB Clocks: - MPU : 650 MHz - MCU : 208.878 MHz - AXI : 266.500 MHz - PER : 24 MHz - DDR : 533 MHz stpmic1_pmic stpmic@33: stpmic1_read: failed to read register 0x25 : -16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x25 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x25 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x2a :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x26 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x21 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x22 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x23 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x25 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x26 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write register 0x29 :-16stpmic1_pmic stpmic@33: stpmic1_write: failed to write regi�Core: 275 devices, 40 uclasses, devicetree: board WDT: Started watchdog@5a002000 with servicing (32s timeout) NAND: 0 MiB MMC: STM32 SD/MMC: 0 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: eth0: ethernet@5800a000 Hit any key to stop autoboot: 0 I think the code should be inserted AFTER the test "if (!stop)" I modify the patch with -- drivers/i2c/stm32f7_i2c.c -- index aac592860e1..cd3bcdf8d99 100644 @@ -477,13 +477,12 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, if (ret) break; -/* End of transfer, send stop condition */ -mask = STM32_I2C_CR2_STOP; -setbits_le32(®s->cr2, mask); - if (!stop) /* Message sent, new message has to be sent */ return 0; + +/* End of transfer, send stop condition */ +setbits_le32(®s->cr2, STM32_I2C_CR2_STOP); } } And the boot is OK, I2C read/tested is OK test with the 2 available device on the board = STPMIC1 & STUSB1600 STM32MP> i2c bus Bus 4: i2c@40012000 Bus 3: i2c@5c002000 (active 3) 28: stusb1600@28, offset len 1, flags 0 33: stpmic@33, offset len 1, flags 0 STM32MP> pmic dev stpmic@33 STM32MP> pmic dump Dump pmic: stpmic@33 registers 0x00: 00 10 00 00 00 01 10 00 00 00 00 00 00 00 00 00 0x10: 04 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0x20: 61 79 d9 d9 01 25 61 7d 00 51 0d 00 00 00 00 00 0x30: 61 50 d9 d9 00 24 24 24 01 51 04 00 00 00 00 00 0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x80: ff ff ff cf 00 00 00 00 00 00 00 00 00 00 00 00 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xb0: 00 00 00 00 00 00 00 00 08 00 00 00 00 00 01 02 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xd0: 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 0
[PATCH] stm32mp: stm32prog: improve the partitioning trace
Improve the partitioning trace done in command stm32prog:
- remove the trace "partition: Done" when the GPT partitioning is not done
- indicate the mmc instance used for each 'gpt write' command
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index c391b6c7abb..7ee4590ef26 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1090,7 +1090,6 @@ static int create_gpt_partitions(struct stm32prog_data
*data)
if (!buf)
return -ENOMEM;
- puts("partitions : ");
/* initialize the selected device */
for (i = 0; i < data->dev_nb; i++) {
/* create gpt partition support only for full update on MMC */
@@ -1098,6 +1097,7 @@ static int create_gpt_partitions(struct stm32prog_data
*data)
!data->dev[i].full_update)
continue;
+ printf("partitions on mmc%d: ", data->dev[i].dev_id);
offset = 0;
rootfs_found = false;
memset(buf, 0, buflen);
@@ -1197,8 +1197,8 @@ static int create_gpt_partitions(struct stm32prog_data
*data)
sprintf(buf, "part list mmc %d", data->dev[i].dev_id);
run_command(buf, 0);
#endif
+ puts("done\n");
}
- puts("done\n");
#ifdef DEBUG
run_command("mtd list", 0);
--
2.25.1
Re: [PATCH v3 3/3] i2c: stm32: do not set the STOP condition on error
Hi Alain, On 9/9/22 18:06, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..2db7f44d44 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -483,9 +483,9 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); + /* End of transfer, send stop condition if appropriate */ + if (!ret && !(status & (STM32_I2C_ISR_NACKF | STM32_I2C_ISR_ERRORS))) + setbits_le32(®s->cr2, STM32_I2C_CR2_STOP); return stm32_i2c_check_end_of_message(i2c_priv); } Reviewed-by: Patrick Delaunay Tested-by: Patrick Delaunay [stm32mp157c-dk2] No regression detection on ST Microelectonics board. - No error trace on boot - I2C probe command is OK STM32MP> i2c probe Valid chip addresses: 28 33 - And other tests done with the 2 I2C devices STPMIC1 & STUSB1600 are ok: regulalor command pmic status command USB type C connection/deconnection @Jorge: can you test also for your use-case, thanks Thanks Patrick
Re: [PATCH v4 3/4] i2c: stm32: do not set the STOP condition on error
Hi, On 9/12/22 10:42, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..2db7f44d44 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -483,9 +483,9 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); + /* End of transfer, send stop condition if appropriate */ + if (!ret && !(status & (STM32_I2C_ISR_NACKF | STM32_I2C_ISR_ERRORS))) + setbits_le32(®s->cr2, STM32_I2C_CR2_STOP); return stm32_i2c_check_end_of_message(i2c_priv); } Reviewed-by: Patrick Delaunay Tested-by: Patrick Delaunay [stm32mp157c-dk2] @Jorge: can you test also for your use-case, thanks Thanks Patrick
Re: [PATCH v4 4/4] i2c: stm32: fix usage of rise/fall device tree properties
Hi,
On 9/12/22 10:42, Alain Volmat wrote:
From: Jorge Ramirez-Ortiz
These two device tree properties were not being applied.
Fixes: 1fd9eb68d6 ("i2c: stm32f7: move driver data of each instance in a
privdata")
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 2db7f44d44..1d2dd8e25d 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -914,18 +914,19 @@ static int stm32_of_to_plat(struct udevice *dev)
{
const struct stm32_i2c_data *data;
struct stm32_i2c_priv *i2c_priv = dev_get_priv(dev);
- u32 rise_time, fall_time;
int ret;
data = (const struct stm32_i2c_data *)dev_get_driver_data(dev);
if (!data)
return -EINVAL;
- rise_time = dev_read_u32_default(dev, "i2c-scl-rising-time-ns",
-STM32_I2C_RISE_TIME_DEFAULT);
+ i2c_priv->setup.rise_time = dev_read_u32_default(dev,
+
"i2c-scl-rising-time-ns",
+
STM32_I2C_RISE_TIME_DEFAULT);
- fall_time = dev_read_u32_default(dev, "i2c-scl-falling-time-ns",
-STM32_I2C_FALL_TIME_DEFAULT);
+ i2c_priv->setup.fall_time = dev_read_u32_default(dev,
+
"i2c-scl-falling-time-ns",
+
STM32_I2C_FALL_TIME_DEFAULT);
i2c_priv->dnf_dt = dev_read_u32_default(dev, "i2c-digital-filter-width-ns", 0);
if (!dev_read_bool(dev, "i2c-digital-filter"))
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Reviewed-by: Patrick Delaunay
Tested-by: Patrick Delaunay
[stm32mp157c-dk2]
No regression detection on ST Microelectonics board.
- No error trace on boot
- I2C probe command is OK
STM32MP> i2c probe
Valid chip addresses: 28 33
- And other tests done with the 2 I2C devices STPMIC1 & STUSB1600 are ok:
regulalor command
pmic status command
USB type C connection/deconnection
@Jorge: can you test also for your use-case, thanks
Thanks
Patrick
Re: [PATCH v2 1/2] usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT
Hi,
On 9/9/22 14:24, Marek Vasut wrote:
On 9/9/22 11:45, Patrick Delaunay wrote:
Add a new CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to increase the
HUB_DEBOUNCE_TIMEOUT value, for example to 2s because some usb device
needs around 1.5s or more to make the hub port status to be
connected steadily after being powered off and powered on.
This 2s value is aligned with Linux driver and avoids to configure
"usb_pgood_delay" as a workaround for connection timeout on
some USB device; normally the env variable "usb_pgood_delay" is used
to delay the first query after power ON and thus the device answer,
but this variable not used to increase the connection timeout delay.
I realized this has one problem -- what happens if you have multiple
USB controllers in your system ? The answer is, all of them are
affected by the increased delay, possibly even those which do not
require the extra delay.
Would it be possible to configure this per-controller (or should this
even be per-device?) in DT ? In fact, I wonder whether this is not
becoming a Vbus regulator ramp-up time kind of delay here ?
Yes, but I don't think, it is blocking.
This timeout will be common for all the USB HUB in the system, as it is
done in Linux kernel.
And I don't thing the issue is linked to VBUS regulator rampup, because
- with USB analyser we check that the answer for the problematic key are
really slow,
no answer in the 1s normal delay
- and any issue on vbus can be handled by query_delay = pgood delay =
the power is stablized before the devices are queried.
But For our use case, increasing pgood delay is not enought the
problematic
(low cost / poor quality / slow) USB keys.
So this CONFIG is used to support some slow USB devices on any USB HUB,
and it is not a workaround for HUB issue.
For my point of view 1s is a little penalty for usb start to support
more USB devices on all
the USB HUB on the system, even when the 1s delay defined by the spec is
not supported.
For kernel this delay is not managed by the device tree but hardcoded in
the USB HUB driver
drivers/usb/core/hub.c
#define HUB_DEBOUNCE_TIMEOUT 2000
/* USB 2.0 spec, 7.1.7.3 / fig 7-29:
*
* Between connect detection and reset signaling there must be a delay
* of 100ms at least for debounce and power-settling. The corresponding
* timer shall restart whenever the downstream port detects a disconnect.
*
* Apparently there are some bluetooth and irda-dongles and a number of
* low-speed devices for which this debounce period may last over a second.
* Not covered by the spec - but easy to deal with.
*
* This implementation uses a 1500ms total debounce timeout; if the
* connection isn't stable by then it returns -ETIMEDOUT. It checks
* every 25ms for transient disconnects. When the port status has been
* unchanged for 100ms it returns the port status.
*/
inthub_port_debounce(structusb_hub *hub, intport1, boolmust_be_connected)
For me in U-Boot driver this debounce is managed as Linux kernel (with
1s <=> 2s)
=> in U-Boot the connect_timeout is used in usb_scan_port():
1- the port is removed from the list when usb_get_port_status() return a
error
during the connect_timeout
2- the port is removed when the when usb_get_port_status() return no error
and the connection change happened,
=> no issue when the PORT is become ready and connected
the usb_get_port_status() will be return no error
and the portstatus (answer of USB_REQ_GET_STATUS)
is handled by usb_scan_port()
=> the potential issue for timeout is when the PORT is ready (no error
for usb_get_port_status())
and not connection detected portchange = 0 / portstatus = 0 after
reset
in usb_scan_port():
/*
* No connection change happened, wait a bit more.
*
* For some situation, the hub reports no connection change but a
* device is connected to the port (eg: CCS bit is set but CSC is not
* in the PORTSC register of a root hub), ignore such case.
*/
if (!(portchange & USB_PORT_STAT_C_CONNECTION) &&
!(portstatus & USB_PORT_STAT_CONNECTION)) {
if (get_timer(0) >= hub->connect_timeout) {
debug("devnum=%d port=%d: timeout\n",
dev->devnum, i + 1);
/* Remove this device from scanning list */
list_del(&usb_scan->list);
free(usb_scan);
return 0;
}
return 0;
}
I think the "connect_timeout" could be not used here
as TIMEOUT for "No connection change happened, wait a bit more."
In linux kernel a other timeout is used: HUB_DEBOUNCE_STABLE = 100ms
for this condition...
when usb_get_port_status() return not error and the the connectio
is STABLE during this duration, it is enought.
Perhaps a optimization can be done here
but I think it is a other subject and I am not enough
[PATCH] board: st: stm32mp1: use of correct compatible string to add partitions
From: Christophe Kerello
Current compatible string used to update SPI NAND and SPI NOR devices
can lead to a wrong partitions update (for example, SPI NAND partitions
added to SPI NOR node in the device tree). To avoid this wrong behavior,
use jedec,spi-nor compatible string for SPI NOR devices and spi-nand
compatible string for SPI NAND devices.
Signed-off-by: Christophe Kerello
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 8c162b42a59..7dc26f850ff 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -898,8 +898,8 @@ int mmc_get_env_dev(void)
int ft_board_setup(void *blob, struct bd_info *bd)
{
static const struct node_info nodes[] = {
- { "st,stm32f469-qspi", MTD_DEV_TYPE_NOR, },
- { "st,stm32f469-qspi", MTD_DEV_TYPE_SPINAND},
+ { "jedec,spi-nor", MTD_DEV_TYPE_NOR, },
+ { "spi-nand", MTD_DEV_TYPE_SPINAND},
{ "st,stm32mp15-fmc2", MTD_DEV_TYPE_NAND, },
{ "st,stm32mp1-fmc2-nfc", MTD_DEV_TYPE_NAND, },
};
--
2.25.1
Re: [PATCH] confis: stm32mp15: activate DM_REGULATOR_SCMI
Hi,
On 9/9/22 11:57, Patrice CHOTARD wrote:
Hi Patrick
Don't forget to fix the confis/configs when applying this patch ;-)
On 9/7/22 18:18, Patrick Delaunay wrote:
Activate the support of SCMI regulator to support the scmi_reg11,
scmi_reg18 and scmi_usb33 regulators present in the scmi device tree of
STMicroelectronics boards with stm32mp15-scmi.dtsi
Fixes: 68d396bf ("ARM: dts: stm32: add SCMI version of STM32 boards
(DK1/DK2/ED1/EV1)")
Signed-off-by: Patrick Delaunay
---
configs/stm32mp15_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index fd2a5de8d13..0f6b3738cad 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -120,6 +120,7 @@ CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_DM_REGULATOR_STM32_VREFBUF=y
CONFIG_DM_REGULATOR_STPMIC1=y
+CONFIG_DM_REGULATOR_SCMI=y
CONFIG_REMOTEPROC_STM32_COPRO=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
Reviewed-by: Patrice Chotard
Applied to u-boot-stm/master, thanks!
I just change the commit title to "configs: stm32mp15: activate
DM_REGULATOR_SCMI"
Regards
Patrick
Re: [PATCHv2 1/2] i2c: stm32f7: fix clearing the control register
Hi, On 8/15/22 16:52, Jorge Ramirez-Ortiz wrote: Bits should be set to 0, not 1. Signed-off-by: Jorge Ramirez-Ortiz --- drivers/i2c/stm32f7_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index bf2a6c9b4b..3a727e68ac 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -413,7 +413,7 @@ static int stm32_i2c_check_end_of_message(struct stm32_i2c_priv *i2c_priv) setbits_le32(®s->icr, STM32_I2C_ICR_STOPCF); /* Clear control register 2 */ - setbits_le32(®s->cr2, STM32_I2C_CR2_RESET_MASK); + clrbits_le32(®s->cr2, STM32_I2C_CR2_RESET_MASK); } return ret; Applied to u-boot-stm/master, thanks! Regards Patrick
Re: [PATCH v4 1/4] i2c: stm32: fix comment and remove unused AUTOEND bit
Hi Alain,
On 9/12/22 10:41, Alain Volmat wrote:
Comment within stm32_i2c_message_start is misleading, indicating
that AUTOEND bit is setted while it is actually cleared.
Moreover, the bit is actually never setted so there is no need
to clear it hence get rid of this bit clear and the bit macro
as well.
Signed-off-by: Alain Volmat
Reviewed-by: Patrick Delaunay
---
drivers/i2c/stm32f7_i2c.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf2a6c9b4b..78d7156492 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -57,7 +57,6 @@ struct stm32_i2c_regs {
#define STM32_I2C_CR1_PE BIT(0)
/* STM32 I2C control 2 */
-#define STM32_I2C_CR2_AUTOEND BIT(25)
#define STM32_I2C_CR2_RELOAD BIT(24)
#define STM32_I2C_CR2_NBYTES_MASK GENMASK(23, 16)
#define STM32_I2C_CR2_NBYTES(n) ((n & 0xff) << 16)
@@ -304,9 +303,8 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
cr2 |= STM32_I2C_CR2_SADD7(msg->addr);
}
- /* Set nb bytes to transfer and reload or autoend bits */
- cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD |
-STM32_I2C_CR2_AUTOEND);
+ /* Set nb bytes to transfer and reload (if needed) */
+ cr2 &= ~(STM32_I2C_CR2_NBYTES_MASK | STM32_I2C_CR2_RELOAD);
if (msg->len > STM32_I2C_MAX_LEN) {
cr2 |= STM32_I2C_CR2_NBYTES(STM32_I2C_MAX_LEN);
cr2 |= STM32_I2C_CR2_RELOAD;
Applied to u-boot-stm/master, thanks!
I also add the missing Reviewed-by when I get the patch from patchwork
http://patchwork.ozlabs.org/project/uboot/patch/20220912084201.1826979-2-alain.vol...@foss.st.com/
+ Reviewed-by: Heiko Schocher
+ Reviewed-by: Patrice Chotard
Regards
Patrick
Re: [PATCH v4 2/4] i2c: stm32: remove unused stop parameter in start & reload handling
Hi Alain,
On 9/12/22 10:41, Alain Volmat wrote:
Functions stm32_i2c_message_start and stm32_i2c_handle_reload
both get a stop boolean indicating if the transfer should end with
a STOP or not. However no specific handling is needed in those
functions hence remove the parameter.
Signed-off-by: Alain Volmat
Reviewed-by: Patrick Delaunay
---
drivers/i2c/stm32f7_i2c.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 78d7156492..0ec67b5c12 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -282,7 +282,7 @@ static int stm32_i2c_check_device_busy(struct
stm32_i2c_priv *i2c_priv)
}
static void stm32_i2c_message_start(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -325,7 +325,7 @@ static void stm32_i2c_message_start(struct stm32_i2c_priv
*i2c_priv,
*/
static void stm32_i2c_handle_reload(struct stm32_i2c_priv *i2c_priv,
- struct i2c_msg *msg, bool stop)
+ struct i2c_msg *msg)
{
struct stm32_i2c_regs *regs = i2c_priv->regs;
u32 cr2 = readl(®s->cr2);
@@ -431,7 +431,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
/* Add errors */
mask |= STM32_I2C_ISR_ERRORS;
- stm32_i2c_message_start(i2c_priv, msg, stop);
+ stm32_i2c_message_start(i2c_priv, msg);
while (msg->len) {
/*
@@ -469,7 +469,7 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv
*i2c_priv,
mask = msg->flags & I2C_M_RD ? STM32_I2C_ISR_RXNE :
STM32_I2C_ISR_TXIS | STM32_I2C_ISR_NACKF;
- stm32_i2c_handle_reload(i2c_priv, msg, stop);
+ stm32_i2c_handle_reload(i2c_priv, msg);
} else if (!bytes_to_rw) {
/* Wait until TC flag is set */
mask = STM32_I2C_ISR_TC;
Applied to u-boot-stm/master, thanks!
I also add the missing Reviewed-by when I get the patch from patchwork
http://patchwork.ozlabs.org/project/uboot/patch/20220912084201.1826979-3-alain.vol...@foss.st.com/
+ Reviewed-by: Heiko Schocher
+ Reviewed-by: Patrice Chotard
Regards
Patrick
Re: [PATCH v4 3/4] i2c: stm32: do not set the STOP condition on error
Hi Alain On 9/12/22 10:42, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..2db7f44d44 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -483,9 +483,9 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); + /* End of transfer, send stop condition if appropriate */ + if (!ret && !(status & (STM32_I2C_ISR_NACKF | STM32_I2C_ISR_ERRORS))) + setbits_le32(®s->cr2, STM32_I2C_CR2_STOP); return stm32_i2c_check_end_of_message(i2c_priv); } Applied to u-boot-stm/master, thanks! I also add the missing Reviewed-by when I get the patch from patchwork http://patchwork.ozlabs.org/project/uboot/patch/20220912084201.1826979-4-alain.vol...@foss.st.com/ + Reviewed-by: Patrice Chotard + Reviewed-by: Heiko Schocher + Reviewed-by: Patrick Delaunay + Tested-by: Patrick Delaunay Regards Patrick
Re: [PATCH v4 3/4] i2c: stm32: do not set the STOP condition on error
Hi Alain, On 9/12/22 10:42, Alain Volmat wrote: Current function stm32_i2c_message_xfer is sending a STOP whatever the result of the transaction is. This can cause issues such as making the bus busy since the controller itself is already sending automatically a STOP when a NACK is generated. Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first fix for this. [1] [1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jo...@foundries.io/ Reported-by: Jorge Ramirez-Ortiz, Foundries Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Alain Volmat --- drivers/i2c/stm32f7_i2c.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c index 0ec67b5c12..2db7f44d44 100644 --- a/drivers/i2c/stm32f7_i2c.c +++ b/drivers/i2c/stm32f7_i2c.c @@ -483,9 +483,9 @@ static int stm32_i2c_message_xfer(struct stm32_i2c_priv *i2c_priv, } } - /* End of transfer, send stop condition */ - mask = STM32_I2C_CR2_STOP; - setbits_le32(®s->cr2, mask); + /* End of transfer, send stop condition if appropriate */ + if (!ret && !(status & (STM32_I2C_ISR_NACKF | STM32_I2C_ISR_ERRORS))) + setbits_le32(®s->cr2, STM32_I2C_CR2_STOP); return stm32_i2c_check_end_of_message(i2c_priv); } Applied to u-boot-stm/master, thanks! I also add the missing Reviewed-by when I get the patch from patchwork http://patchwork.ozlabs.org/project/uboot/patch/20220912084201.1826979-5-alain.vol...@foss.st.com/ + Reviewed-by: Patrice Chotard + Reviewed-by: Heiko Schocher + Reviewed-by: Patrick Delaunay + Tested-by: Patrick Delaunay Regards Patrick
[PULL] Pull request for u-boot master / v2022.10 = u-boot-stm32-20220915
Hi Tom, Please pull the STM32 related fixes for u-boot/master, v2022.10: u-boot-stm32-20220915 - Fixes on STM32 I2C drivers - Activate SCMI regulator for STM32MP15 defconfig, fix the usb start command for scmi device tree CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/13457 Thanks, Patrick git request-pull origin/master https://source.denx.de/u-boot/custodians/u-boot-stm.git/ u-boot-stm32-20220915 The following changes since commit d6a03711fde2a6c99614af20ee95a9efe7ad232b: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2022-09-13 08:19:42 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git/ tags/u-boot-stm32-20220915 for you to fetch changes up to a22692dd815c20b3fc6354be954ce65922761ad1: i2c: stm32: fix usage of rise/fall device tree properties (2022-09-15 14:59:29 +0200) - Fixes on STM32 I2C drivers - Activate SCMI regulator for STM32MP15 defconfig, fix the usb start command for scmi device tree Alain Volmat (3): i2c: stm32: fix comment and remove unused AUTOEND bit i2c: stm32: remove unused stop parameter in start & reload handling i2c: stm32: do not set the STOP condition on error Jorge Ramirez-Ortiz (2): i2c: stm32f7: fix clearing the control register i2c: stm32: fix usage of rise/fall device tree properties Patrick Delaunay (1): configs: stm32mp15: activate DM_REGULATOR_SCMI configs/stm32mp15_defconfig | 1 + drivers/i2c/stm32f7_i2c.c | 33 - 2 files changed, 17 insertions(+), 17 deletions(-)
Re: [PATCH v4 4/4] i2c: stm32: fix usage of rise/fall device tree properties
Hi Alain,
On 9/12/22 10:42, Alain Volmat wrote:
From: Jorge Ramirez-Ortiz
These two device tree properties were not being applied.
Fixes: 1fd9eb68d6 ("i2c: stm32f7: move driver data of each instance in a
privdata")
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Alain Volmat
---
drivers/i2c/stm32f7_i2c.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index 2db7f44d44..1d2dd8e25d 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -914,18 +914,19 @@ static int stm32_of_to_plat(struct udevice *dev)
{
const struct stm32_i2c_data *data;
struct stm32_i2c_priv *i2c_priv = dev_get_priv(dev);
- u32 rise_time, fall_time;
int ret;
data = (const struct stm32_i2c_data *)dev_get_driver_data(dev);
if (!data)
return -EINVAL;
- rise_time = dev_read_u32_default(dev, "i2c-scl-rising-time-ns",
-STM32_I2C_RISE_TIME_DEFAULT);
+ i2c_priv->setup.rise_time = dev_read_u32_default(dev,
+
"i2c-scl-rising-time-ns",
+
STM32_I2C_RISE_TIME_DEFAULT);
- fall_time = dev_read_u32_default(dev, "i2c-scl-falling-time-ns",
-STM32_I2C_FALL_TIME_DEFAULT);
+ i2c_priv->setup.fall_time = dev_read_u32_default(dev,
+
"i2c-scl-falling-time-ns",
+
STM32_I2C_FALL_TIME_DEFAULT);
i2c_priv->dnf_dt = dev_read_u32_default(dev, "i2c-digital-filter-width-ns", 0);
if (!dev_read_bool(dev, "i2c-digital-filter"))
Applied to u-boot-stm/master, thanks!
I also add the missing Reviewed-by when I get the patch from patchwork
http://patchwork.ozlabs.org/project/uboot/patch/20220912084201.1826979-5-alain.vol...@foss.st.com/
+ Reviewed-by: Patrice Chotard
+ Reviewed-by: Heiko Schocher
+ Reviewed-by: Patrick Delaunay
+ Tested-by: Patrick Delaunay
Regards
Patrick
[PATCH 0/4] arm: stm32mp: adapt the command stm32key for STM32MP13x
And support the 2 keys for STM32MP13x - PKHTH : Hash of the 8 ECC Public Keys Hashes Table (ECDSA is the authentication algorithm) - EDMK : Encryption/Decryption Master Key Only one key is supported for STM32MP15x - PKH : Hash of the ECC Public Key (ECDSA is the authentication algorithm) This STM32KEY command is used in STM32MP SoCs to provision the keys in the correct OTP needed to activate secure boot features: authentication and encryption. See [1] for details [1] STM32 MPU wiki https://wiki.st.com/stm32mpu/wiki/How_to_use_U-Boot_stm32key_command Patrick Delaunay (4): arm: stm32mp: add defines for BSEC_LOCK status in stm32key command arm: stm32mp: introduced read_close_status function in stm32key command arm: stm32mp: support several key in command stm32key arm: stm32mp: adapt the command stm32key for STM32MP13x arch/arm/mach-stm32mp/cmd_stm32key.c | 331 --- 1 file changed, 249 insertions(+), 82 deletions(-) -- 2.25.1
[PATCH 1/4] arm: stm32mp: add defines for BSEC_LOCK status in stm32key command
Add defines for value used in stm32key for BSEC permanent lock status
and error.
This patch is a preliminary step to support more lock status in BSEC
driver.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32key.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32key.c
b/arch/arm/mach-stm32mp/cmd_stm32key.c
index 68f28922d1e..1899d91ecb5 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32key.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32key.c
@@ -19,6 +19,9 @@
#define STM32_OTP_HASH_KEY_START 24
#define STM32_OTP_HASH_KEY_SIZE8
+#define BSEC_LOCK_ERROR(-1)
+#define BSEC_LOCK_PERM BIT(0)
+
static int get_misc_dev(struct udevice **dev)
{
int ret;
@@ -60,14 +63,14 @@ static int read_hash_otp(bool print, bool *locked, bool
*closed)
val = ~0x0;
ret = misc_read(dev, STM32_BSEC_LOCK(word), &lock, 4);
if (ret != 4)
- lock = -1;
+ lock = BSEC_LOCK_ERROR;
if (print)
- printf("OTP HASH %i: %x lock : %d\n", word, val, lock);
+ printf("OTP HASH %i: %x lock : %x\n", word, val, lock);
if (val == ~0x0)
nb_invalid++;
else if (val == 0x0)
nb_zero++;
- if (lock == 1)
+ if (lock & BSEC_LOCK_PERM)
nb_lock++;
}
@@ -77,13 +80,13 @@ static int read_hash_otp(bool print, bool *locked, bool
*closed)
val = 0x0;
ret = misc_read(dev, STM32_BSEC_LOCK(word), &lock, 4);
if (ret != 4)
- lock = -1;
+ lock = BSEC_LOCK_ERROR;
status = (val & STM32_OTP_CLOSE_MASK) == STM32_OTP_CLOSE_MASK;
if (closed)
*closed = status;
if (print)
- printf("OTP %d: closed status: %d lock : %d\n", word, status,
lock);
+ printf("OTP %d: closed status: %d lock : %x\n", word, status,
lock);
status = (nb_lock == STM32_OTP_HASH_KEY_SIZE);
if (locked)
@@ -128,7 +131,7 @@ static int fuse_hash_value(u32 addr, bool print)
return ret;
}
/* on success, lock the OTP for HASH key */
- val = 1;
+ val = BSEC_LOCK_PERM;
ret = misc_write(dev, STM32_BSEC_LOCK(word), &val, 4);
if (ret != 4) {
log_err("Lock OTP %i failed\n", word);
--
2.25.1
[PATCH 3/4] arm: stm32mp: support several key in command stm32key
Update the command stm32key to support several keys selected by
key name and managed by the new sub-command:
stm32key list
stm32key select []
stm32key read -a
This patch doesn't change the STM32MP15 behavior, only PKH is
supported, but it is a preliminary patch for STM32MP13 support.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32key.c | 195 ---
1 file changed, 149 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32key.c
b/arch/arm/mach-stm32mp/cmd_stm32key.c
index 68f9b1a9a59..4eac56082db 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32key.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32key.c
@@ -15,9 +15,37 @@
#define STM32_OTP_CLOSE_ID 0
#define STM32_OTP_CLOSE_MASK BIT(6)
-/* HASH of key: 8 OTPs, starting with OTP24) */
-#define STM32_OTP_HASH_KEY_START 24
-#define STM32_OTP_HASH_KEY_SIZE8
+/* PKH is the first element of the key list */
+#define STM32KEY_PKH 0
+
+struct stm32key {
+ char *name;
+ char *desc;
+ u8 start;
+ u8 size;
+};
+
+const struct stm32key stm32mp15_list[] = {
+ [STM32KEY_PKH] = {
+ .name = "PKH",
+ .desc = "Hash of the ECC Public Key (ECDSA is the
authentication algorithm)",
+ .start = 24,
+ .size = 8,
+ }
+};
+
+/* index of current selected key in stm32key list, 0 = PKH by default */
+static u8 stm32key_index;
+
+static u8 get_key_nb(void)
+{
+ return ARRAY_SIZE(stm32mp15_list);
+}
+
+static const struct stm32key *get_key(u8 index)
+{
+ return &stm32mp15_list[index];
+}
#define BSEC_LOCK_ERROR(-1)
#define BSEC_LOCK_PERM BIT(0)
@@ -33,26 +61,25 @@ static int get_misc_dev(struct udevice **dev)
return ret;
}
-static void read_hash_value(u32 addr)
+static void read_key_value(const struct stm32key *key, u32 addr)
{
int i;
- printf("Read KEY at 0x%x\n", addr);
- for (i = 0; i < STM32_OTP_HASH_KEY_SIZE; i++) {
- printf("OTP value %i: %x\n", STM32_OTP_HASH_KEY_START + i,
- __be32_to_cpu(*(u32 *)addr));
+ for (i = 0; i < key->size; i++) {
+ printf("%s OTP %i: [%08x] %08x\n", key->name, key->start + i,
+ addr, __be32_to_cpu(*(u32 *)addr));
addr += 4;
}
}
-static int read_hash_otp(struct udevice *dev, bool print, bool *locked)
+static int read_key_otp(struct udevice *dev, const struct stm32key *key, bool
print, bool *locked)
{
int i, word, ret;
- int nb_invalid = 0, nb_zero = 0, nb_lock = 0;
+ int nb_invalid = 0, nb_zero = 0, nb_lock = 0, nb_lock_err = 0;
u32 val, lock;
bool status;
- for (i = 0, word = STM32_OTP_HASH_KEY_START; i <
STM32_OTP_HASH_KEY_SIZE; i++, word++) {
+ for (i = 0, word = key->start; i < key->size; i++, word++) {
ret = misc_read(dev, STM32_BSEC_OTP(word), &val, 4);
if (ret != 4)
val = ~0x0;
@@ -60,29 +87,33 @@ static int read_hash_otp(struct udevice *dev, bool print,
bool *locked)
if (ret != 4)
lock = BSEC_LOCK_ERROR;
if (print)
- printf("OTP HASH %i: %x lock : %x\n", word, val, lock);
+ printf("%s OTP %i: %08x lock : %08x\n", key->name,
word, val, lock);
if (val == ~0x0)
nb_invalid++;
else if (val == 0x0)
nb_zero++;
if (lock & BSEC_LOCK_PERM)
nb_lock++;
+ if (lock & BSEC_LOCK_ERROR)
+ nb_lock_err++;
}
- status = (nb_lock == STM32_OTP_HASH_KEY_SIZE);
+ status = nb_lock_err || (nb_lock == key->size);
if (locked)
*locked = status;
- if (!status && print)
- printf("Hash of key is not locked!\n");
+ if (nb_lock_err && print)
+ printf("%s lock is invalid!\n", key->name);
+ else if (!status && print)
+ printf("%s is not locked!\n", key->name);
- if (nb_invalid == STM32_OTP_HASH_KEY_SIZE) {
+ if (nb_invalid == key->size) {
if (print)
- printf("Hash of key is invalid!\n");
+ printf("%s is invalid!\n", key->name);
return -EINVAL;
}
- if (nb_zero == STM32_OTP_HASH_KEY_SIZE) {
+ if (nb_zero == key->size) {
if (print)
- printf("Hash of key is free!\n");
+ printf("%s is free!\n", key->name);
return -ENOENT;
[PATCH 2/4] arm: stm32mp: introduced read_close_status function in stm32key command
Split the read_hash_otp function and introduce the helper function
read_close_status to read the close status in OTP separately of the PKH.
This patch is a preliminary step for STM32MP13 support.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32key.c | 107 ---
1 file changed, 65 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32key.c
b/arch/arm/mach-stm32mp/cmd_stm32key.c
index 1899d91ecb5..68f9b1a9a59 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32key.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32key.c
@@ -45,18 +45,13 @@ static void read_hash_value(u32 addr)
}
}
-static int read_hash_otp(bool print, bool *locked, bool *closed)
+static int read_hash_otp(struct udevice *dev, bool print, bool *locked)
{
- struct udevice *dev;
int i, word, ret;
int nb_invalid = 0, nb_zero = 0, nb_lock = 0;
u32 val, lock;
bool status;
- ret = get_misc_dev(&dev);
- if (ret)
- return ret;
-
for (i = 0, word = STM32_OTP_HASH_KEY_START; i <
STM32_OTP_HASH_KEY_SIZE; i++, word++) {
ret = misc_read(dev, STM32_BSEC_OTP(word), &val, 4);
if (ret != 4)
@@ -74,20 +69,6 @@ static int read_hash_otp(bool print, bool *locked, bool
*closed)
nb_lock++;
}
- word = STM32_OTP_CLOSE_ID;
- ret = misc_read(dev, STM32_BSEC_OTP(word), &val, 4);
- if (ret != 4)
- val = 0x0;
- ret = misc_read(dev, STM32_BSEC_LOCK(word), &lock, 4);
- if (ret != 4)
- lock = BSEC_LOCK_ERROR;
-
- status = (val & STM32_OTP_CLOSE_MASK) == STM32_OTP_CLOSE_MASK;
- if (closed)
- *closed = status;
- if (print)
- printf("OTP %d: closed status: %d lock : %x\n", word, status,
lock);
-
status = (nb_lock == STM32_OTP_HASH_KEY_SIZE);
if (locked)
*locked = status;
@@ -108,16 +89,40 @@ static int read_hash_otp(bool print, bool *locked, bool
*closed)
return 0;
}
-static int fuse_hash_value(u32 addr, bool print)
+static int read_close_status(struct udevice *dev, bool print, bool *closed)
+{
+ int word, ret, result;
+ u32 val, lock;
+ bool status;
+
+ result = 0;
+ word = STM32_OTP_CLOSE_ID;
+ ret = misc_read(dev, STM32_BSEC_OTP(word), &val, 4);
+ if (ret < 0)
+ result = ret;
+ if (ret != 4)
+ val = 0x0;
+
+ ret = misc_read(dev, STM32_BSEC_LOCK(word), &lock, 4);
+ if (ret < 0)
+ result = ret;
+ if (ret != 4)
+ lock = BSEC_LOCK_ERROR;
+
+ status = (val & STM32_OTP_CLOSE_MASK) == STM32_OTP_CLOSE_MASK;
+ if (closed)
+ *closed = status;
+ if (print)
+ printf("OTP %d: closed status: %d lock : %x\n", word, status,
lock);
+
+ return result;
+}
+
+static int fuse_hash_value(struct udevice *dev, u32 addr, bool print)
{
- struct udevice *dev;
u32 word, val;
int i, ret;
- ret = get_misc_dev(&dev);
- if (ret)
- return ret;
-
for (i = 0, word = STM32_OTP_HASH_KEY_START;
i < STM32_OTP_HASH_KEY_SIZE;
i++, word++, addr += 4) {
@@ -158,10 +163,20 @@ static int confirm_prog(void)
static int do_stm32key_read(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
{
+ struct udevice *dev;
u32 addr;
+ int ret;
+
+ ret = get_misc_dev(&dev);
if (argc == 1) {
- read_hash_otp(true, NULL, NULL);
+ if (ret)
+ return CMD_RET_FAILURE;
+ read_hash_otp(dev, true, NULL);
+ ret = read_close_status(dev, true, NULL);
+ if (ret)
+ return CMD_RET_FAILURE;
+
return CMD_RET_SUCCESS;
}
@@ -176,8 +191,10 @@ static int do_stm32key_read(struct cmd_tbl *cmdtp, int
flag, int argc, char *con
static int do_stm32key_fuse(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
{
+ struct udevice *dev;
u32 addr;
- bool yes = false, lock, closed;
+ int ret;
+ bool yes = false, lock;
if (argc < 2)
return CMD_RET_USAGE;
@@ -192,20 +209,23 @@ static int do_stm32key_fuse(struct cmd_tbl *cmdtp, int
flag, int argc, char *con
if (!addr)
return CMD_RET_USAGE;
- if (read_hash_otp(!yes, &lock, &closed) != -ENOENT) {
+ ret = get_misc_dev(&dev);
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ if (read_hash_otp(dev, !yes, &lock) != -ENOENT) {
printf("Error: can't fuse again the OTP\n");
return CMD_RET_FAILURE;
}
-
- if (lock || closed) {
- printf("Error
[PATCH 4/4] arm: stm32mp: adapt the command stm32key for STM32MP13x
Change the mask of OTP0 used to close the device on STM32MP
- STM32MP15x: bit 6 of OPT0
- STM32MP13x: 0b11 = 0x3F for OTP_SECURED closed device
And support the 2 keys for STM32MP13x
- PKHTH : Hash of the 8 ECC Public Keys Hashes Table
(ECDSA is the authentication algorithm)
- EDMK : Encryption/Decryption Master Key
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cmd_stm32key.c | 52
1 file changed, 45 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32key.c
b/arch/arm/mach-stm32mp/cmd_stm32key.c
index 4eac56082db..278253e472f 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32key.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32key.c
@@ -11,9 +11,14 @@
#include
#include
-/* Closed device : bit 6 of OPT0*/
+/*
+ * Closed device: OTP0
+ * STM32MP15x: bit 6 of OPT0
+ * STM32MP13x: 0b11 = 0x3F for OTP_SECURED closed device
+ */
#define STM32_OTP_CLOSE_ID 0
-#define STM32_OTP_CLOSE_MASK BIT(6)
+#define STM32_OTP_STM32MP13x_CLOSE_MASK0x3F
+#define STM32_OTP_STM32MP15x_CLOSE_MASKBIT(6)
/* PKH is the first element of the key list */
#define STM32KEY_PKH 0
@@ -25,6 +30,21 @@ struct stm32key {
u8 size;
};
+const struct stm32key stm32mp13_list[] = {
+ [STM32KEY_PKH] = {
+ .name = "PKHTH",
+ .desc = "Hash of the 8 ECC Public Keys Hashes Table (ECDSA is
the authentication algorithm)",
+ .start = 24,
+ .size = 8,
+ },
+ {
+ .name = "EDMK",
+ .desc = "Encryption/Decryption Master Key",
+ .start = 92,
+ .size = 4,
+ }
+};
+
const struct stm32key stm32mp15_list[] = {
[STM32KEY_PKH] = {
.name = "PKH",
@@ -39,12 +59,29 @@ static u8 stm32key_index;
static u8 get_key_nb(void)
{
- return ARRAY_SIZE(stm32mp15_list);
+ if (IS_ENABLED(CONFIG_STM32MP13x))
+ return ARRAY_SIZE(stm32mp13_list);
+
+ if (IS_ENABLED(CONFIG_STM32MP15x))
+ return ARRAY_SIZE(stm32mp15_list);
}
static const struct stm32key *get_key(u8 index)
{
- return &stm32mp15_list[index];
+ if (IS_ENABLED(CONFIG_STM32MP13x))
+ return &stm32mp13_list[index];
+
+ if (IS_ENABLED(CONFIG_STM32MP15x))
+ return &stm32mp15_list[index];
+}
+
+static u32 get_otp_close_mask(void)
+{
+ if (IS_ENABLED(CONFIG_STM32MP13x))
+ return STM32_OTP_STM32MP13x_CLOSE_MASK;
+
+ if (IS_ENABLED(CONFIG_STM32MP15x))
+ return STM32_OTP_STM32MP15x_CLOSE_MASK;
}
#define BSEC_LOCK_ERROR(-1)
@@ -123,7 +160,7 @@ static int read_key_otp(struct udevice *dev, const struct
stm32key *key, bool pr
static int read_close_status(struct udevice *dev, bool print, bool *closed)
{
int word, ret, result;
- u32 val, lock;
+ u32 val, lock, mask;
bool status;
result = 0;
@@ -140,7 +177,8 @@ static int read_close_status(struct udevice *dev, bool
print, bool *closed)
if (ret != 4)
lock = BSEC_LOCK_ERROR;
- status = (val & STM32_OTP_CLOSE_MASK) == STM32_OTP_CLOSE_MASK;
+ mask = get_otp_close_mask();
+ status = (val & mask) == mask;
if (closed)
*closed = status;
if (print)
@@ -371,7 +409,7 @@ static int do_stm32key_close(struct cmd_tbl *cmdtp, int
flag, int argc, char *co
if (!yes && !confirm_prog())
return CMD_RET_FAILURE;
- val = STM32_OTP_CLOSE_MASK;
+ val = get_otp_close_mask();
ret = misc_write(dev, STM32_BSEC_OTP(STM32_OTP_CLOSE_ID), &val, 4);
if (ret != 4) {
printf("Error: can't update OTP %d\n", STM32_OTP_CLOSE_ID);
--
2.25.1
[PATCH] configs: stm32mp1: cleanup config file
Remove the unnecessary comment after the CONFIG_SYS_BOOTM_LEN
migration to Kconfig.
Fixes: c45568cc4e51 ("Convert CONFIG_SYS_BOOTM_LEN to Kconfig")
Signed-off-by: Patrick Delaunay
---
include/configs/stm32mp13_common.h | 2 --
include/configs/stm32mp15_common.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/configs/stm32mp13_common.h
b/include/configs/stm32mp13_common.h
index 3ca65ea2a37..78089b965ae 100644
--- a/include/configs/stm32mp13_common.h
+++ b/include/configs/stm32mp13_common.h
@@ -21,8 +21,6 @@
*/
#define CONFIG_SYS_BOOTMAPSZ SZ_256M
-/* Extend size of kernel image for uncompression */
-
/*MMC SD*/
#define CONFIG_SYS_MMC_MAX_DEVICE 2
diff --git a/include/configs/stm32mp15_common.h
b/include/configs/stm32mp15_common.h
index c5412ffeb31..bd8e16bc1b9 100644
--- a/include/configs/stm32mp15_common.h
+++ b/include/configs/stm32mp15_common.h
@@ -21,8 +21,6 @@
*/
#define CONFIG_SYS_BOOTMAPSZ SZ_256M
-/* Extend size of kernel image for uncompression */
-
/*MMC SD*/
#define CONFIG_SYS_MMC_MAX_DEVICE 3
--
2.25.1
[PATCH v4] tee: optee: rework TA bus scanning code
Hi Simon,
On 9/12/22 20:31, Simon Glass wrote:
Hi Ilias,
On Wed, 7 Sept 2022 at 15:32, Ilias Apalodimas
wrote:
Hi Simon,
On Thu, 8 Sept 2022 at 00:11, Simon Glass wrote:
Hi Ilias,
On Tue, 6 Sept 2022 at 15:23, Ilias Apalodimas
wrote:
Hi Simon,
On Tue, Sep 06, 2022 at 03:18:28PM -0600, Simon Glass wrote:
Hi,
On Tue, 6 Sept 2022 at 03:37, Ilias Apalodimas
wrote:
Late versions of OP-TEE support a pseudo bus. TAs that behave as
hardware blocks (e.g TPM, RNG etc) present themselves on a bus
whichwe can
scan. Unfortunately U-Boot doesn't support that yet. It's worth
noting
that we already have a workaround for RNG. The details are in
commit 70812bb83da6 ("tee: optee: bind rng optee driver")
So let's add a list of devices based on U-Boot Kconfig options
that we will
scan until we properly implement the tee-bus functionality.
While at it change the behaviour of the tee core itself wrt to device
binding. If some device binding fails, print a warning instead of
disabling OP-TEE.
Signed-off-by: Ilias Apalodimas
Reviewed-by: Jens Wiklander
Reviewed-by: Etienne Carriere
---
Changes since v3:
- Use NULL instead of a child ptr on device_bind_driver(), since
it's not
really needed
- Changed the style of the optee_bus_probe[] definition to
{.drv_name = xxx, .dev_name = yyy }
Changes since v2:
- Fixed typo on driver name ftpm-tee -> ftpm_tee
Changes since v1:
- remove a macro and use ARRAY_SIZE directly
drivers/tee/optee/core.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index a89d62aaf0b3..c201a4635e6b 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -31,6 +31,18 @@ struct optee_pdata {
optee_invoke_fn *invoke_fn;
};
+static const struct {
+ const char *drv_name;
+ const char *dev_name;
+} optee_bus_probe[] = {
+#ifdef CONFIG_RNG_OPTEE
+ { .drv_name = "optee-rng", .dev_name = "optee-rng" },
+#endif
+#ifdef CONFIG_TPM2_FTPM_TEE
+ { .drv_name = "ftpm_tee", .dev_name = "ftpm_tee" },
+#endif
+};
+
struct rpc_param {
u32 a0;
u32 a1;
@@ -642,8 +654,7 @@ static int optee_probe(struct udevice *dev)
{
struct optee_pdata *pdata = dev_get_plat(dev);
u32 sec_caps;
- struct udevice *child;
- int ret;
+ int ret, i;
if (!is_optee_api(pdata->invoke_fn)) {
dev_err(dev, "OP-TEE api uid mismatch\n");
@@ -672,10 +683,13 @@ static int optee_probe(struct udevice *dev)
* in U-Boot, the discovery of TA on the TEE bus is not supported:
* only bind the drivers associated to the supported OP-TEETA
*/
- if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
- ret = device_bind_driver(dev, "optee-rng", "optee-rng", &child);
+
+ for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
+ ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
+ optee_bus_probe[i].dev_name, NULL);
if (ret)
- return ret;
+ dev_warn(dev, "Failed to bind device %s\n",
+ optee_bus_probe[i].dev_name);
Please add device tree nodes for these and all this code can go away.
That's the exact opposite of what the commit message describes. OP-TEE
supports a scannable bus ifor TAs that behave like hardware blocks and
doesn't need a DT entry. Since it's really the TAs compilation decision
to support that or not having them as a DT node is not always the right
choice.
This is continuing the perversion of how things are supposed to work
in driver model.
Which is not the only thing we need to keep in mind though.
We need to talk about this because it is simply the wrong way to be
approaching this.
This is already part of other software components though, e.g it's
already in the kernel. So I don't think it's the wrong approach.
There is nothing wrong with putting things in the DT
and this is how U-Boot works. For now, please create a binding and get
it reviewed. You don't need all the internal objects but you do need
an OP-TEE driver and node, as we have with PCI.
Some things *are* working without a DT entry. You had similar
concerns on FF-A (where you requested a DT node again) and people gave
the exact same response. As long as a bus is scanable in any way,
it's preferable to than adding a DT entry. Moreover this code does
not prevent anyone from adding a DT entry.
To make things even worse if the TA is compiled as 'scanable' and has
a DT entry, it might cause issues down the road when being probed by
the kernel. So really this is just a patch that makes u-boot behave
and plug in properly to the rest of the ecosystem
Calling device_bind() is supposed to be used in extremis. I don't see
any scanning of an OP-TEE bus here. I just see it binding two child
devices which are hard-coded in U-Boot. What am I missing?
The tee bus is supported in Linux kernel (each TA have a UUID and
is discoverable by the TEE driver).
see drivers/tee/optee/core.c::optee_bus_scan()
and "struct tee_client_driver" with TA UUID
It wasn't supported in U-Boot is the first TEE/OP-TEE driver implementation
=> TA support was hardcoded, under the associated CONFI
Re: [PATCH] configs: stm32mp*: reset via CONFIG_RESET_SCMI
Hi, On 9/5/22 19:01, Oleksandr Suvorov wrote: Jorge, I think, renaming the patch to "fix" and adding a field "Fixes:" should help accept it faster. On Mon, Sep 5, 2022 at 7:32 PM Jorge Ramirez-Ortiz, Foundries wrote: On 30/08/22, Jorge Ramirez-Ortiz wrote: Enabling CONFIG_SYSRESET_PSCI prevents CONFIG_RESET_SCMI from executing. The side effect observed are I2C devices no longer being accessible from U-boot after a soft reset. I think this PR should get a bit more of attention. The current reset configuration is broken, this is a fix. Do I need to rename the PR? TIA jorge Signed-off-by: Jorge Ramirez-Ortiz --- configs/stm32mp13_defconfig | 1 - configs/stm32mp15_defconfig | 1 - configs/stm32mp15_trusted_defconfig | 1 - 3 files changed, 3 deletions(-) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index 673b468d31..44cee2e656 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -69,7 +69,6 @@ CONFIG_RNG_OPTEE=y CONFIG_DM_RTC=y CONFIG_RTC_STM32=y CONFIG_SERIAL_RX_BUFFER=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index e5a2996c2c..2ad02f3652 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -133,7 +133,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_STM32_QSPI=y CONFIG_STM32_SPI=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index e14668042f..9e24e82920 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -134,7 +134,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_STM32_QSPI=y CONFIG_STM32_SPI=y -CONFIG_SYSRESET_PSCI=y CONFIG_TEE=y CONFIG_OPTEE=y # CONFIG_OPTEE_TA_AVB is not set -- 2.34.1 This patch it is superseded by "configs: stm32mp*: fix system reset" http://patchwork.ozlabs.org/project/uboot/list/?series=316914&state=* http://patchwork.ozlabs.org/project/uboot/patch/20220905173357.2231466-1-jo...@foundries.io/ with the added "Fixes:" Regards Patrick
