Re: [PATCH 1/2] ARM: dts: stm32: add PWR regulators support on stm32mp131
On 4/21/24 22:27, Marek Vasut wrote: > On 3/19/24 3:45 AM, Marek Vasut wrote: >> This patch adds STM32 PWR regulators DT support on stm32mp131. >> This requires TFA to clear RCC_SECCFGR, is disabled by default >> and can only be enabled on board DT level. >> >> Signed-off-by: Marek Vasut > > It seems these patches have been missed from the recent PR ? > > Is there any feedback on those patches ? Hi Marek Yes, these patches was voluntary suspended on our side due to internal discussion. On my side these patches are ok. They will be part on next STM32 pull request. Thanks Patrice
[PATCH v2] stm32mp: Reserve OPTEE area in EFI memory map
Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
memory region above ram_top is tagged in EFI memory map as
EFI_BOOT_SERVICES_DATA.
In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one
reserved-memory region tagged "no-map" dedicated to OP-TEE :
_ addr=de00 size=200 for stm32mp157x-dkx and stm32mp135f-dk
_ addr=fe00 size=200 for stm32mp157c-ev1
Before booting kernel, EFI memory map is first built, the OPTEE region is
tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
is used.
Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
which try to add again the same OPTEE region (addr=de00 size=200
in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe00 size=200
in case for stm2mp157c-ev1)
but now with LMB_NOMAP tag which produces the following error message :
_ for stm32mp157x-dkx / stm32mp135f-dk :
"ERROR: reserving fdt memory region failed (addr=de00 size=200
flags=4)"
_ for stm32mp157c-ev1 :
"ERROR: reserving fdt memory region failed (addr=fe00 size=200
flags=4)"
To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
it as reserved.
Signed-off-by: Patrice Chotard
---
Changes in v2:
_ update commit message by adding information about memory area
dedicated for OPTEE for various STM32MP1/STM32MP13 boards.
arch/arm/mach-stm32mp/dram_init.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-stm32mp/dram_init.c
b/arch/arm/mach-stm32mp/dram_init.c
index fb1208fc5d5..f67f54f2ae0 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
return reg + size;
}
+
+void efi_add_known_memory(void)
+{
+ if (IS_ENABLED(CONFIG_EFI_LOADER))
+ /*
+* Memory over ram_top is reserved to OPTEE.
+* Declare to EFI only memory area below ram_top
+*/
+ efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
+ EFI_CONVENTIONAL_MEMORY);
+}
--
2.25.1
Re: [Uboot-stm32] [PATCH] stm32mp: Reserve OPTEE area in EFI memory map
On 4/19/24 09:44, Patrice CHOTARD wrote:
>
>
> On 4/17/24 09:45, Heinrich Schuchardt wrote:
>> On 17.04.24 09:25, Patrick DELAUNAY wrote:
>>> Hi,
>>>
>>> On 3/8/24 11:12, Patrice Chotard wrote:
>>>> Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
>>>> memory region above ram_top is tagged in EFI memory map as
>>>> EFI_BOOT_SERVICES_DATA.
>>>> In case of STM32MP1 platform, above ram_top, there is one reserved-memory
>>>> region tagged "no-map" dedicated to OP-TEE (addr=de00 size=200).
>>>>
>>>> Before booting kernel, EFI memory map is first built, the OPTEE region is
>>>> tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
>>>> is used.
>>>>
>>>> Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
>>>> which try to add again the same OPTEE region (addr=de00 size=200)
>>>> but now with LMB_NOMAP tag which produces the following error message :
>>>>
>>>> "ERROR: reserving fdt memory region failed (addr=de00 size=200
>>>> flags=4)"
>>>>
>>>> To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
>>>> it as reserved.
>>>>
>>>> Signed-off-by: Patrice Chotard
>>>> ---
>>>>
>>>> arch/arm/mach-stm32mp/dram_init.c | 12
>>>> 1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-stm32mp/dram_init.c
>>>> b/arch/arm/mach-stm32mp/dram_init.c
>>>> index fb1208fc5d5..f67f54f2ae0 100644
>>>> --- a/arch/arm/mach-stm32mp/dram_init.c
>>>> +++ b/arch/arm/mach-stm32mp/dram_init.c
>>>> @@ -7,6 +7,7 @@
>>>> #include
>>>> #include
>>>> +#include
>>>> #include
>>>> #include
>>>> #include
>>>> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
>>>> total_size)
>>>> return reg + size;
>>>> }
>>>> +
>>>> +void efi_add_known_memory(void)
>>>> +{
>>>> + if (IS_ENABLED(CONFIG_EFI_LOADER))
>>>> + /*
>>>> + * Memory over ram_top is reserved to OPTEE.
>>>> + * Declare to EFI only memory area below ram_top
>>>> + */
>>>> + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
>>>> + EFI_CONVENTIONAL_MEMORY);
>>
>> With this change the EFI memory map passed to the operating system will
>> not contain any memory above gd->ram_top. Is this really your intent?
>> Don't you have any memory above 0xe000?
>
> Hi Heinrich
>
> On stm32mp157x-dk and stm32mp135x-dk boards, there is no memory above
> 0xe000.
> But, on stm32mp157x-ed1 or stm32mp157x-ev1, you are right, we got memory
> above 0xe000.
>
> I will rework this patch to take into account memory that could be present
> above OPTEE area.
After double checking, this patch is correct but i need to update the commit
message.
In fact for stm32mp157x-dk and stm32mp135x-dk boards, there is 512MB of memory
(0xc000 0x2000),
OPTEE is located at the end of memory : 0xde00 0x0200
But for stm32mp157c-ev1, there is 1GB of memory (0xC000 0x4000), and
identically,
OPTEE is located at the end of memory : 0xfe00 0x200
So in both cases, above OPTEE reserved-memory area, there is no more free
memory.
Thanks
Patrice
>
> Thanks for pointing this
> Patrice
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>> +}
>>>
>>>
>>>
>>> Reviewed-by: Patrick Delaunay
>>>
>>> Thanks
>>> Patrick
>>>
>>
> ___
> Uboot-stm32 mailing list
> uboot-st...@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [PATCH 3/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot
On 4/17/24 11:00, Patrick DELAUNAY wrote:
> Hi,
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 partition node name with correct offset.
>>
>> Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for stm32mp15xx-dhcom/dhcor")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> index 2f70b0690d2..1b445619325 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> @@ -106,15 +106,15 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@50 {
>> + partition@8 {
>> label = "uboot";
>> reg = <0x0008 0x0016>;
>> };
>> - partition@90 {
>> + partition@1e {
>> label = "env1";
>> reg = <0x001E 0x0001>;
>> };
>> - partition@98 {
>> + partition@1f {
>> label = "env2";
>> reg = <0x001F 0x0001>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH 1/3] ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot
On 4/17/24 10:59, Patrick DELAUNAY wrote:
> Hi,
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 and nand@0 partition node name with correct offset.
>>
>> Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for stm32mp15xx-ev1")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> index 139940bd5d4..3515347e91d 100644
>> --- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> @@ -33,11 +33,11 @@
>> label = "fsbl1";
>> reg = <0x 0x0004>;
>> };
>> - partition@8 {
>> + partition@4 {
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@10 {
>> + partition@8 {
>> label = "ssbl";
>> reg = <0x0008 0x0020>;
>> };
>> @@ -58,7 +58,7 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@10 {
>> + partition@8 {
>> label = "fip";
>> reg = <0x0008 0x0040>;
>> };
>> @@ -112,7 +112,7 @@
>> label = "fip2";
>> reg = <0x0060 0x0040>;
>> };
>> - partition@120 {
>> + partition@a0 {
>> label = "UBI";
>> reg = <0x00a0 0x3f60>;
>> };
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
>
Applied on u-boot-stm32/master
Re: [PATCH 2/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot
On 4/17/24 11:00, Patrick DELAUNAY wrote:
> Hi
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 partition node name with correct offset.
>>
>> Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for
>> stm32mp15xx-dhcom/dhcor")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> index 552b35db3c7..ba84db679e1 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> @@ -42,15 +42,15 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@50 {
>> + partition@8 {
>> label = "uboot";
>> reg = <0x0008 0x0016>;
>> };
>> - partition@90 {
>> + partition@1e {
>> label = "env1";
>> reg = <0x001E 0x0001>;
>> };
>> - partition@98 {
>> + partition@1f {
>> label = "env2";
>> reg = <0x001F 0x0001>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible
On 4/17/24 13:10, Jaehoon Chung wrote:
> Hi
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
>> Subject: Re: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2"
>> compatible
>>
>> Hi,
>>
>> On 3/8/24 15:26, Patrice Chotard wrote:
>>> From: Patrick Delaunay
>>>
>>> Add compatible used for STM32MP25 family.
>>>
>>> Signed-off-by: Patrick Delaunay
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> drivers/mmc/stm32_sdmmc2.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
>>> index a2b111a8435..d4982a14281 100644
>>> --- a/drivers/mmc/stm32_sdmmc2.c
>>> +++ b/drivers/mmc/stm32_sdmmc2.c
>>> @@ -789,6 +789,7 @@ static int stm32_sdmmc2_bind(struct udevice *dev)
>>>
>>> static const struct udevice_id stm32_sdmmc2_ids[] = {
>>> { .compatible = "st,stm32-sdmmc2" },
>>> + { .compatible = "st,stm32mp25-sdmmc2" },
>>> { }
>>> };
>>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Thanks
>> Patrick
>>
>
>
Applied on u-boot-stm32/master
Re: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
On 4/17/24 13:11, Jaehoon Chung wrote:
>
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
>> Subject: Re: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
>>
>> Hi,
>>
>> On 3/8/24 15:26, Patrice Chotard wrote:
>>> When building with AARCH64 defconfig, we got warnings, fix them.
>>>
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> drivers/mmc/stm32_sdmmc2.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
>>> index d4982a14281..39ae79ba129 100644
>>> --- a/drivers/mmc/stm32_sdmmc2.c
>>> +++ b/drivers/mmc/stm32_sdmmc2.c
>>> @@ -220,9 +220,9 @@ static void stm32_sdmmc2_start_data(struct udevice *dev,
>>>
>>> if (data->flags & MMC_DATA_READ) {
>>> data_ctrl |= SDMMC_DCTRL_DTDIR;
>>> - idmabase0 = (u32)data->dest;
>>> + idmabase0 = (u32)(long)data->dest;
>>> } else {
>>> - idmabase0 = (u32)data->src;
>>> + idmabase0 = (u32)(long)data->src;
>>> }
>>>
>>> /* Set the SDMMC DataLength value */
>>> @@ -463,8 +463,8 @@ retry_cmd:
>>>
>>> stm32_sdmmc2_start_cmd(dev, cmd, cmdat, );
>>>
>>> - dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%x\n",
>>> - cmd->cmdidx, data ? ctx.data_length : 0, (unsigned int)data);
>>> + dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%p\n",
>>> + cmd->cmdidx, data ? ctx.data_length : 0, data);
>>>
>>> ret = stm32_sdmmc2_end_cmd(dev, cmd, );
>>>
>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Thanks
>> Patrick
>
>
Applied on u-boot-stm32/master
Re: [PATCH v1 25/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:28, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> The blue led is used to indicate U-Boot entering / exit indication >> then Linux heartbeat. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 24/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:13, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> As indicated in kernel led dt-bindings, label is a deprecated >> property, so remove it and use led node's name instead for >> u-boot,error-led property. >> Rename red led node's name to led-red. >> Remove status property which is useless. >> Add compatible = "gpio-leds"; which is not present in kernel DT. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:13, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> red led and button dedicated to fastboot share the same gpio GPIOA13. >> Led driver is probed early so the corresponding gpio is taken and >> configured in output which forbid fastboot and stm32prog button usage. >> >> To avoid this, remove the "default-state" property from red led node. >> >> This will avoid to trigger the led driver probe() to configure the led >> default state during startup. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 - >> 1 file changed, 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
On 4/9/24 17:02, Patrice Chotard wrote:
> red led and button dedicated to fastboot share the same gpio GPIOA13.
> Led driver is probed early so the corresponding gpio is taken and
> configured in output which forbid fastboot and stm32prog button usage.
>
> To avoid this, remove the "default-state" property from red led node.
>
> This will avoid to trigger the led driver probe() to configure the led
> default state during startup.
>
> Signed-off-by: Patrice Chotard
> ---
>
> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> index 84920f53496..2abd512e297 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> @@ -37,7 +37,6 @@
> red {
> label = "error";
> gpios = < 13 GPIO_ACTIVE_LOW>;
> - default-state = "off";
> status = "okay";
> };
> };
Applied on u-boot-stm32/master
Re: [PATCH v1 22/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:12, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Add 2 gpio-keys : >> _ button-user-1 for stm32prog mode activation. >> _ button-user-2 for fastboot mode activation. >> >> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 21/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> The blue led is used to indicate U-Boot entering / exit indication >> then Linux heartbeat. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 20/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> As indicated in kernel led dt-bindings, label is a deprecated >> property, so remove it and use led node's name instead for >> u-boot,error-led property. >> Rename red led node's name to led-red. >> Remove status property which is useless. >> Add compatible = "gpio-leds" which is not present in kernel DT. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 19/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> red led and button dedicated to fastboot share the same gpio GPIOA13. >> Led driver is probed early so the corresponding gpio is taken and >> configured in output which forbid fastboot and stm32prog button usage. >> >> To avoid this, remove the "default-state" property from red led node. >> >> This will avoid to trigger the led driver probe() to configure the led >> default state during startup. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 1 - >> 1 file changed, 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 18/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Add 2 gpio-keys : >> _ button-user-1 for stm32prog mode activation. >> _ button-user-2 for fastboot mode activation. >> >> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 17/25] ARM: dts: stm32: Update u-boot,boot-led for stm32mp157a-dk1-u-boot
On 4/17/24 11:10, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> As indicated in kernel led dt-bindings, label is a deprecated >> property, so remove it and use blue led node's name instead >> for u-boot,boot-led property. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 16/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
On 4/17/24 11:10, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> As indicated in kernel led dt-bindings, label is a deprecated >> property, so remove it and use red led node's name instead >> for u-boot,error-led property. >> Rename red led node's name to led-red. >> Remove status property which is useless. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 ++ >> 1 file changed, 2 insertions(+), 4 deletions(-) > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 15/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog button usage.
>>
>> To avoid this, remove the "default-state" property from red led node.
>>
>> This will avoid to trigger the led driver probe() to configure the led
>> default state during startup.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> index 6bf6136c5fd..ee9b51d42b7 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> @@ -67,7 +67,6 @@
>> red {
>> label = "error";
>> gpios = < 13 GPIO_ACTIVE_LOW>;
>> - default-state = "off";
>> status = "okay";
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 14/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare >> 2 gpio-keys. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 13/25] ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use blue led node's name instead
>> for u-boot,boot-led property.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index e61814fd66e..a5158fec7ef 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -13,7 +13,7 @@
>> };
>> config {
>> - u-boot,boot-led = "heartbeat";
>> + u-boot,boot-led = "led-blue";
>> u-boot,error-led = "led-red";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = < 18>, < 19>;
>> @@ -36,6 +36,10 @@
>> };
>> led {
>> + led-blue {
>> + /delete-property/label;
>> + };
>> +
>> led-red {
>> gpios = < 13 GPIO_ACTIVE_LOW>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 12/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:08, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> As indicated in kernel led dt-bindings, label is a deprecated
>> property, so remove it and use red led node's name instead
>> for u-boot,error-led property.
>> Rename "red" led node's name to "led-red".
>> Remove status property which is useless.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 8760d6c7d93..e61814fd66e 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -14,7 +14,7 @@
>> config {
>> u-boot,boot-led = "heartbeat";
>> - u-boot,error-led = "error";
>> + u-boot,error-led = "led-red";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = < 18>, < 19>;
>> };
>> @@ -36,10 +36,8 @@
>> };
>> led {
>> - red {
>> - label = "error";
>> + led-red {
>> gpios = < 13 GPIO_ACTIVE_LOW>;
>> - status = "okay";
>> };
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 11/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> red led and button dedicated to fastboot share the same gpio GPIOA13.
>> Led driver is probed early so the corresponding gpio is taken and
>> configured in output which forbid fastboot and stm32prog button usage.
>>
>> To avoid this, remove the "default-state" property from red led node.
>>
>> This will avoid to trigger the led driver probe() to configure the led
>> default state during startup.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 5d49b09c35d..8760d6c7d93 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -39,7 +39,6 @@
>> red {
>> label = "error";
>> gpios = < 13 GPIO_ACTIVE_LOW>;
>> - default-state = "off";
>> status = "okay";
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 10/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
>> 2 gpio-keys.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 19 +--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 20728f27ee1..5d49b09c35d 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -3,6 +3,7 @@
>> * Copyright : STMicroelectronics 2022
>> */
>> +#include
>> #include "stm32mp15-scmi-u-boot.dtsi"
>> / {
>> @@ -16,8 +17,22 @@
>> u-boot,error-led = "error";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = < 18>, < 19>;
>> - st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> - st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> +
>> + button-user-1 {
>> + label = "User-1";
>> + linux,code = ;
>> + gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> +
>> + button-user-2 {
>> + label = "User-2";
>> + linux,code = ;
>> + gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> };
>> led {
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 09/25] ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Remove "color" property from led-red node which is not supported
>> by U-Boot.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> index 8f42735609a..f004e9840a2 100644
>> --- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> @@ -35,7 +35,6 @@
>> };
>> led-red {
>> - color = ;
>> gpios = < 13 GPIO_ACTIVE_LOW>;
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 08/25] ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
On 4/17/24 11:06, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> led-red and button dedicated to fastboot share the same gpio GPIOA13. >> led-blue and button dedicated to stm32prog share the same gpio GPIOA14. >> Led driver is probed early so the corresponding gpio is taken and >> configured in output which forbid fastboot and stm32prog button usage. >> >> To avoid this, remove the "default-state" property from led-red and >> led-blue led's node. >> >> This will avoid to trigger the led driver probe() to configure the led >> default state during startup. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 06/25] board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()
On 4/17/24 11:05, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Instead of using gpio directly to detect key pressed on button >> dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS. >> >> Signed-off-by: Patrice Chotard >> --- >> >> board/st/stm32mp1/stm32mp1.c | 68 +--- >> 1 file changed, 40 insertions(+), 28 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 07/25] ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
On 4/17/24 11:06, Patrick DELAUNAY wrote: > Hi > > On 4/9/24 17:01, Patrice Chotard wrote: >> Add 2 gpio-keys : >> _ button-user-1 for stm32prog mode activation. >> _ update button-user's label (defined in kernel DT) to match label >> requested in board_key_check() for fastboot mode activation. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 13 + >> 1 file changed, 13 insertions(+) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 05/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig
On 4/18/24 13:48, Igor Opaniuk wrote: > On Tue, Apr 9, 2024 at 5:05 PM Patrice Chotard > wrote: >> >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp13_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig >> index db09e63100e..caaabf39ef3 100644 >> --- a/configs/stm32mp13_defconfig >> +++ b/configs/stm32mp13_defconfig >> @@ -52,6 +52,8 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_SYS_MMC_ENV_DEV=-1 >> CONFIG_ENV_MMC_USE_DT=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y >> -- >> 2.25.1 >> > > Reviewed-by: Igor Opaniuk Applied on u-boot-stm32/master
Re: [PATCH v1 03/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig
On 4/17/24 11:04, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_basic_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_basic_defconfig >> b/configs/stm32mp15_basic_defconfig >> index 005f1d55f80..2e22bf86000 100644 >> --- a/configs/stm32mp15_basic_defconfig >> +++ b/configs/stm32mp15_basic_defconfig >> @@ -97,6 +97,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y >> CONFIG_FASTBOOT_BUF_ADDR=0xC000 > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 04/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig
On 4/17/24 11:04, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_trusted_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_trusted_defconfig >> b/configs/stm32mp15_trusted_defconfig >> index 84b0854b557..74deaaba2e4 100644 >> --- a/configs/stm32mp15_trusted_defconfig >> +++ b/configs/stm32mp15_trusted_defconfig >> @@ -70,6 +70,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 02/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig
On 4/17/24 11:03, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig >> index 3302b306996..ffe7512650e 100644 >> --- a/configs/stm32mp15_defconfig >> +++ b/configs/stm32mp15_defconfig >> @@ -69,6 +69,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 01/25] configs: stm32mp13: Enable FASTBOOT
On 4/18/24 13:48, Igor Opaniuk wrote: > On Tue, Apr 9, 2024 at 5:19 PM Patrice Chotard > wrote: >> >> Enable FASTBOOT relative flags for stm32mp13_defconfig. >> >> Signed-off-by: Patrice Chotard >> >> --- >> >> configs/stm32mp13_defconfig | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig >> index c893e272db9..db09e63100e 100644 >> --- a/configs/stm32mp13_defconfig >> +++ b/configs/stm32mp13_defconfig >> @@ -15,6 +15,7 @@ CONFIG_CMD_STM32PROG=y >> CONFIG_SYS_LOAD_ADDR=0xc200 >> CONFIG_SYS_MEMTEST_START=0xc000 >> CONFIG_SYS_MEMTEST_END=0xc400 >> +# CONFIG_ANDROID_BOOT_IMAGE is not set >> CONFIG_FIT=y >> CONFIG_SYS_BOOTM_LEN=0x200 >> CONFIG_DISTRO_DEFAULTS=y >> @@ -53,6 +54,13 @@ CONFIG_SYS_MMC_ENV_DEV=-1 >> CONFIG_ENV_MMC_USE_DT=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> +CONFIG_USB_FUNCTION_FASTBOOT=y >> +CONFIG_FASTBOOT_BUF_ADDR=0xc000 >> +CONFIG_FASTBOOT_BUF_SIZE=0x0200 >> +CONFIG_FASTBOOT_FLASH=y >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 >> +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y >> +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y >> CONFIG_GPIO_HOG=y >> CONFIG_DM_I2C=y >> CONFIG_SYS_I2C_STM32F7=y >> @@ -92,7 +100,6 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" >> CONFIG_USB_GADGET_VENDOR_NUM=0x0483 >> CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 >> CONFIG_USB_GADGET_DWC2_OTG=y >> -CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_ERRNO_STR=y >> # CONFIG_LMB_USE_MAX_REGIONS is not set >> CONFIG_LMB_MEMORY_REGIONS=2 >> -- >> 2.25.1 >> > Reviewed-by: Igor Opaniuk > Applied on u-boot-stm32/master
Re: [PATCH] stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD
On 2/7/24 16:59, Igor Opaniuk wrote: > On Wed, Feb 7, 2024 at 2:12 PM Patrick Delaunay > wrote: >> >> This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated >> in defconfig, with undefined reference to run_usb_dnl_gadget and to >> g_dnl_set_product. >> >> Signed-off-by: Patrick Delaunay >> --- >> >> arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> index 8f91db4b46b9..589276282e44 100644 >> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> @@ -17,6 +17,7 @@ config CMD_STM32PROG >> config CMD_STM32PROG_USB >> bool "support stm32prog over USB" >> depends on CMD_STM32PROG >> + depends on USB_GADGET_DOWNLOAD >> default y >> help >> activate the command "stm32prog usb" for STM32MP soc family >> -- >> 2.25.1 >> > > Reviewed-by: Igor Opaniuk Applied on u-boot-stm32/master
Re: [PATCH] arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM
On 3/4/24 19:25, Marek Vasut wrote: > The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it. > This used to be enabled implicitly before, now that implicit dependency > disappeared and this got disabled. Enable it manually. > > Signed-off-by: Marek Vasut > --- > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > configs/stm32mp15_dhcom_basic_defconfig | 2 ++ > configs/stm32mp15_dhcor_basic_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 1d241529be7..0bfd3b76d6a 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y > CONFIG_SPL_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > CONFIG_USB_DWC2=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 6e0c4a8cf9f..1c1fbc5c7db 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y > CONFIG_SPL_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > CONFIG_USB_DWC2=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y Applied on u-boot-stm32/master
Re: [PATCH] mtd: rawnand: stm32_fmc2: add MP25 support
On 3/6/24 10:54, Christophe Kerello wrote:
> FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are
> available when on MP25 SoC, the 4 chip select are available.
>
> Let's use a platform data structure for parameters that will differ.
>
> Signed-off-by: Christophe Kerello
> ---
>
> drivers/mtd/nand/raw/stm32_fmc2_nand.c | 47 ++
> 1 file changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 3528824575b..d284b8cbb12 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -34,7 +34,7 @@
> #define FMC2_RB_DELAY_US 30
>
> /* Max chip enable */
> -#define FMC2_MAX_CE 2
> +#define FMC2_MAX_CE 4
>
> /* Timings */
> #define FMC2_THIZ1
> @@ -160,6 +160,11 @@ static inline struct stm32_fmc2_nand
> *to_fmc2_nand(struct nand_chip *chip)
> return container_of(chip, struct stm32_fmc2_nand, chip);
> }
>
> +struct stm32_fmc2_nfc_data {
> + int max_ncs;
> + struct udevice *(*get_cdev)(struct udevice *dev);
> +};
> +
> struct stm32_fmc2_nfc {
> struct nand_hw_control base;
> struct stm32_fmc2_nand nand;
> @@ -169,6 +174,7 @@ struct stm32_fmc2_nfc {
> fdt_addr_t cmd_base[FMC2_MAX_CE];
> fdt_addr_t addr_base[FMC2_MAX_CE];
> struct clk clk;
> + const struct stm32_fmc2_nfc_data *data;
>
> u8 cs_assigned;
> int cs_sel;
> @@ -815,7 +821,7 @@ static int stm32_fmc2_nfc_parse_child(struct
> stm32_fmc2_nfc *nfc, ofnode node)
> }
>
> for (i = 0; i < nand->ncs; i++) {
> - if (cs[i] >= FMC2_MAX_CE) {
> + if (cs[i] >= nfc->data->max_ncs) {
> log_err("Invalid reg value: %d\n", nand->cs_used[i]);
> return -EINVAL;
> }
> @@ -906,10 +912,18 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> spin_lock_init(>controller.lock);
> init_waitqueue_head(>controller.wq);
>
> - cdev = stm32_fmc2_nfc_get_cdev(dev);
> - if (!cdev)
> + nfc->data = (void *)dev_get_driver_data(dev);
> + if (!nfc->data)
> return -EINVAL;
>
> + if (nfc->data->get_cdev) {
> + cdev = nfc->data->get_cdev(dev);
> + if (!cdev)
> + return -EINVAL;
> + } else {
> + cdev = dev->parent;
> + }
> +
> ret = stm32_fmc2_nfc_parse_dt(dev, nfc);
> if (ret)
> return ret;
> @@ -921,7 +935,7 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> if (dev == cdev)
> start_region = 1;
>
> - for (chip_cs = 0, mem_region = start_region; chip_cs < FMC2_MAX_CE;
> + for (chip_cs = 0, mem_region = start_region; chip_cs <
> nfc->data->max_ncs;
>chip_cs++, mem_region += 3) {
> if (!(nfc->cs_assigned & BIT(chip_cs)))
> continue;
> @@ -1033,9 +1047,28 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> return nand_register(0, mtd);
> }
>
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp1_data = {
> + .max_ncs = 2,
> + .get_cdev = stm32_fmc2_nfc_get_cdev,
> +};
> +
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp25_data = {
> + .max_ncs = 4,
> +};
> +
> static const struct udevice_id stm32_fmc2_nfc_match[] = {
> - { .compatible = "st,stm32mp15-fmc2" },
> - { .compatible = "st,stm32mp1-fmc2-nfc" },
> + {
> + .compatible = "st,stm32mp15-fmc2",
> + .data = (ulong)_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp1-fmc2-nfc",
> + .data = (ulong)_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp25-fmc2-nfc",
> + .data = (ulong)_fmc2_nfc_mp25_data,
> + },
> { /* Sentinel */ }
> };
>
Applied on u-boot-stm32/master
Re: [PATCH v1 2/2] memory: stm32-fmc2-ebi: add MP25 RIF support
On 3/6/24 10:50, Christophe Kerello wrote:
> The FMC2 revision 2 supports security and isolation compliant with
> the Resource Isolation Framework (RIF). From RIF point of view,
> the FMC2 is composed of several independent resources, listed below,
> which can be assigned to different security and compartment domains:
> - 0: Common FMC_CFGR register.
> - 1: EBI controller for Chip Select 1.
> - 2: EBI controller for Chip Select 2.
> - 3: EBI controller for Chip Select 3.
> - 4: EBI controller for Chip Select 4.
> - 5: NAND controller.
>
> Signed-off-by: Christophe Kerello
> ---
>
> drivers/memory/stm32-fmc2-ebi.c | 140 +++-
> 1 file changed, 138 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index c7db16463e8..1ce96077858 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -23,8 +23,14 @@
> #define FMC2_BTR(x) ((x) * 0x8 + FMC2_BTR1)
> #define FMC2_PCSCNTR 0x20
> #define FMC2_CFGR0x20
> +#define FMC2_SR 0x84
> #define FMC2_BWTR1 0x104
> #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
> +#define FMC2_SECCFGR 0x300
> +#define FMC2_CIDCFGR00x30c
> +#define FMC2_CIDCFGR(x) ((x) * 0x8 + FMC2_CIDCFGR0)
> +#define FMC2_SEMCR0 0x310
> +#define FMC2_SEMCR(x)((x) * 0x8 + FMC2_SEMCR0)
>
> /* Register: FMC2_BCR1 */
> #define FMC2_BCR1_CCLKEN BIT(20)
> @@ -67,8 +73,23 @@
> #define FMC2_CFGR_CCLKEN BIT(20)
> #define FMC2_CFGR_FMC2EN BIT(31)
>
> +/* Register: FMC2_SR */
> +#define FMC2_SR_ISOSTGENMASK(1, 0)
> +
> +/* Register: FMC2_CIDCFGR */
> +#define FMC2_CIDCFGR_CFENBIT(0)
> +#define FMC2_CIDCFGR_SEMEN BIT(1)
> +#define FMC2_CIDCFGR_SCIDGENMASK(6, 4)
> +#define FMC2_CIDCFGR_SEMWLC1 BIT(17)
> +
> +/* Register: FMC2_SEMCR */
> +#define FMC2_SEMCR_SEM_MUTEX BIT(0)
> +#define FMC2_SEMCR_SEMCIDGENMASK(6, 4)
> +
> #define FMC2_MAX_EBI_CE 4
> #define FMC2_MAX_BANKS 5
> +#define FMC2_MAX_RESOURCES 6
> +#define FMC2_CID11
>
> #define FMC2_BCR_CPSIZE_00x0
> #define FMC2_BCR_CPSIZE_128 0x1
> @@ -163,6 +184,7 @@ struct stm32_fmc2_ebi_data {
> u32 fmc2_enable_reg;
> u32 fmc2_enable_bit;
> int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> + int (*check_rif)(struct stm32_fmc2_ebi *ebi, u32 resource);
> };
>
> struct stm32_fmc2_ebi {
> @@ -170,6 +192,7 @@ struct stm32_fmc2_ebi {
> fdt_addr_t io_base;
> const struct stm32_fmc2_ebi_data *data;
> u8 bank_assigned;
> + bool access_granted;
> };
>
> /*
> @@ -241,6 +264,28 @@ static int stm32_fmc2_ebi_check_sync_trans(struct
> stm32_fmc2_ebi *ebi,
> return -EINVAL;
> }
>
> +static int stm32_fmc2_ebi_mp25_check_cclk(struct stm32_fmc2_ebi *ebi,
> + const struct stm32_fmc2_prop *prop,
> + int cs)
> +{
> + if (!ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
> +static int stm32_fmc2_ebi_mp25_check_clk_period(struct stm32_fmc2_ebi *ebi,
> + const struct stm32_fmc2_prop
> *prop,
> + int cs)
> +{
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> +
> + if (cfgr & FMC2_CFGR_CCLKEN && !ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
> static int stm32_fmc2_ebi_check_async_trans(struct stm32_fmc2_ebi *ebi,
> const struct stm32_fmc2_prop *prop,
> int cs)
> @@ -960,7 +1005,7 @@ static const struct stm32_fmc2_prop
> stm32_fmc2_mp25_child_props[] = {
> .bprop = true,
> .reg_type = FMC2_REG_CFGR,
> .reg_mask = FMC2_CFGR_CCLKEN,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_cclk,
> .set = stm32_fmc2_ebi_set_bit_field,
> },
> {
> @@ -1058,7 +1103,7 @@ static const struct stm32_fmc2_prop
> stm32_fmc2_mp25_child_props[] = {
> {
> .name = "st,fmc2-ebi-cs-clk-period-ns",
> .reset_val = FMC2_CFGR_CLKDIV_MAX + 1,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_clk_period,
> .calculate = stm32_fmc2_ebi_ns_to_clock_cycles,
> .set = stm32_fmc2_ebi_mp25_set_clk_period,
> },
> @@
Re: [PATCH v1 1/2] memory: stm32-fmc2-ebi: add MP25 support
On 3/6/24 10:50, Christophe Kerello wrote:
> Add the support of the revision 2 of FMC2 IP.
> - PCSCNTR register has been removed,
> - CFGR register has been added,
> - the bit used to enable the IP has moved from BCR1 to CFGR,
> - the timeout for CEx deassertion has moved from PCSCNTR to BCRx,
> - the continuous clock enable has moved from BCR1 to CFGR,
> - the clk divide ratio has moved from BCR1 to CFGR.
>
> The MP1 SoCs have only one signal to manage all the controllers (NWAIT).
> The MP25 SOC has one RNB signal for the NAND controller and one NWAIT
> signal for the memory controller.
>
> Let's use a platform data structure for parameters that will differ
> between MP1 and MP25.
>
> Signed-off-by: Christophe Kerello
>
> ---
>
> drivers/memory/stm32-fmc2-ebi.c | 313 ++--
> 1 file changed, 301 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index a722a3836f7..c7db16463e8 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -22,6 +22,7 @@
> #define FMC2_BCR(x) ((x) * 0x8 + FMC2_BCR1)
> #define FMC2_BTR(x) ((x) * 0x8 + FMC2_BTR1)
> #define FMC2_PCSCNTR 0x20
> +#define FMC2_CFGR0x20
> #define FMC2_BWTR1 0x104
> #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
>
> @@ -44,6 +45,7 @@
> #define FMC2_BCR_ASYNCWAIT BIT(15)
> #define FMC2_BCR_CPSIZE GENMASK(18, 16)
> #define FMC2_BCR_CBURSTRWBIT(19)
> +#define FMC2_BCR_CSCOUNT GENMASK(21, 20)
> #define FMC2_BCR_NBLSET GENMASK(23, 22)
>
> /* Register: FMC2_BTRx/FMC2_BWTRx */
> @@ -60,6 +62,11 @@
> #define FMC2_PCSCNTR_CSCOUNT GENMASK(15, 0)
> #define FMC2_PCSCNTR_CNTBEN(x) BIT((x) + 16)
>
> +/* Register: FMC2_CFGR */
> +#define FMC2_CFGR_CLKDIV GENMASK(19, 16)
> +#define FMC2_CFGR_CCLKEN BIT(20)
> +#define FMC2_CFGR_FMC2EN BIT(31)
> +
> #define FMC2_MAX_EBI_CE 4
> #define FMC2_MAX_BANKS 5
>
> @@ -76,6 +83,11 @@
> #define FMC2_BCR_MTYP_PSRAM 0x1
> #define FMC2_BCR_MTYP_NOR0x2
>
> +#define FMC2_BCR_CSCOUNT_0 0x0
> +#define FMC2_BCR_CSCOUNT_1 0x1
> +#define FMC2_BCR_CSCOUNT_64 0x2
> +#define FMC2_BCR_CSCOUNT_256 0x3
> +
> #define FMC2_BXTR_EXTMOD_A 0x0
> #define FMC2_BXTR_EXTMOD_B 0x1
> #define FMC2_BXTR_EXTMOD_C 0x2
> @@ -90,6 +102,7 @@
> #define FMC2_BTR_CLKDIV_MAX 0xf
> #define FMC2_BTR_DATLAT_MAX 0xf
> #define FMC2_PCSCNTR_CSCOUNT_MAX 0xff
> +#define FMC2_CFGR_CLKDIV_MAX 0xf
>
> enum stm32_fmc2_ebi_bank {
> FMC2_EBI1 = 0,
> @@ -103,7 +116,8 @@ enum stm32_fmc2_ebi_register_type {
> FMC2_REG_BCR = 1,
> FMC2_REG_BTR,
> FMC2_REG_BWTR,
> - FMC2_REG_PCSCNTR
> + FMC2_REG_PCSCNTR,
> + FMC2_REG_CFGR
> };
>
> enum stm32_fmc2_ebi_transaction_type {
> @@ -134,9 +148,27 @@ enum stm32_fmc2_ebi_cpsize {
> FMC2_CPSIZE_1024 = 1024
> };
>
> +enum stm32_fmc2_ebi_cscount {
> + FMC2_CSCOUNT_0 = 0,
> + FMC2_CSCOUNT_1 = 1,
> + FMC2_CSCOUNT_64 = 64,
> + FMC2_CSCOUNT_256 = 256
> +};
> +
> +struct stm32_fmc2_ebi;
> +
> +struct stm32_fmc2_ebi_data {
> + const struct stm32_fmc2_prop *child_props;
> + unsigned int nb_child_props;
> + u32 fmc2_enable_reg;
> + u32 fmc2_enable_bit;
> + int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> +};
> +
> struct stm32_fmc2_ebi {
> struct clk clk;
> fdt_addr_t io_base;
> + const struct stm32_fmc2_ebi_data *data;
> u8 bank_assigned;
> };
>
> @@ -296,6 +328,24 @@ static u32 stm32_fmc2_ebi_ns_to_clk_period(struct
> stm32_fmc2_ebi *ebi,
> return DIV_ROUND_UP(nb_clk_cycles, clk_period);
> }
>
> +static u32 stm32_fmc2_ebi_mp25_ns_to_clk_period(struct stm32_fmc2_ebi *ebi,
> + int cs, u32 setup)
> +{
> + u32 nb_clk_cycles = stm32_fmc2_ebi_ns_to_clock_cycles(ebi, cs, setup);
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> + u32 clk_period;
> +
> + if (cfgr & FMC2_CFGR_CCLKEN) {
> + clk_period = FIELD_GET(FMC2_CFGR_CLKDIV, cfgr) + 1;
> + } else {
> + u32 btr = readl(ebi->io_base + FMC2_BTR(cs));
> +
> + clk_period = FIELD_GET(FMC2_BTR_CLKDIV, btr) + 1;
> + }
> +
> + return DIV_ROUND_UP(nb_clk_cycles, clk_period);
> +}
> +
> static int stm32_fmc2_ebi_get_reg(int reg_type, int cs, u32 *reg)
> {
> switch (reg_type) {
> @@ -311,6 +361,9 @@ static int stm32_fmc2_ebi_get_reg(int reg_type, int cs,
> u32 *reg)
> case FMC2_REG_PCSCNTR:
> *reg = FMC2_PCSCNTR;
> break;
> + case FMC2_REG_CFGR:
> +
Re: [PATCH v2] ARM: stm32: Jump to ep on successful resume in PSCI suspend code
On 4/7/24 22:21, Marek Vasut wrote:
> In case the system has resumed successfully, the PSCI suspend resume
> code has to jump to the 'ep' successful resume entry point code path,
> otherwise the code has to jump to content of the LR register, which
> points to failed resume code path.
>
> To implement this distinction, rewrite LR register stored on stack
> with 'ep' value in case of a successful resume, which is really in
> every case unless some catastrophic failure occurred during suspend.
>
> Without this change, Linux counts every resume as failed in
> /sys/power/suspend_stats/fail
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Rebase on u-boot/master
> ---
> arch/arm/mach-stm32mp/stm32mp1/psci.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> index 8cdeb0ab3f2..4f2379df45f 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> @@ -703,6 +703,8 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
> {
> u32 saved_mcudivr, saved_pll3cr, saved_pll4cr, saved_mssckselr;
> u32 gicd_addr = stm32mp_get_gicd_base_address();
> + u32 cpu = psci_get_cpu_id();
> + u32 sp = (u32)__secure_stack_end - (cpu << ARM_PSCI_STACK_SHIFT);
> bool iwdg1_wake = false;
> bool iwdg2_wake = false;
> bool other_wake = false;
> @@ -805,4 +807,16 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
>
> writel(SYSCFG_CMPENR_MPUEN, STM32_SYSCFG_BASE + SYSCFG_CMPENSETR);
> clrbits_le32(STM32_SYSCFG_BASE + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
> +
> + /*
> + * The system has resumed successfully. Rewrite LR register stored
> + * on stack with 'ep' value, so that on return from this PSCI call,
> + * the code would jump to that 'ep' resume entry point code path
> + * instead of the previous 'lr' register content which (e.g. with
> + * Linux) points to resume failure code path.
> + *
> + * See arch/arm/cpu/armv7/psci.S _smc_psci: for the stack layout
> + * used here, SP-4 is PC, SP-8 is LR, SP-12 is R7, and so on.
> + */
> + writel(ep, sp - 8);
> }
Applied on u-boot-stm32/master
Re: [PATCH] ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o
On 4/14/24 20:38, Marek Vasut wrote: > The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not > in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two > Makefile entries in each subdirectory. Drop the bogus one and keep > only the correct one, the one in arch/arm/mach-stm32mp/Makefile . > > Signed-off-by: Marek Vasut > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > arch/arm/mach-stm32mp/stm32mp1/Makefile | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/Makefile > b/arch/arm/mach-stm32mp/stm32mp1/Makefile > index 857148747ef..ebae50f66c9 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/Makefile > +++ b/arch/arm/mach-stm32mp/stm32mp1/Makefile > @@ -8,7 +8,6 @@ obj-y += cpu.o > obj-$(CONFIG_STM32MP13X) += stm32mp13x.o > obj-$(CONFIG_STM32MP15X) += stm32mp15x.o > > -obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o > ifdef CONFIG_SPL_BUILD > obj-y += spl.o > obj-y += tzc400.o Applied on u-boot-stm32/master
Re: [PATCH] ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
On 4/14/24 20:39, Marek Vasut wrote:
> SoC revision is only accessible via DBUMCU IDC register,
> which requires BSEC.DENABLE DBGSWENABLE bit to be set to
> make the register accessible, otherwise an access to the
> register triggers bus fault. As BSEC.DBGSWENABLE is zero
> in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
> bit as this might open a brief window for timing attacks.
> Instead, report that this system is OTP-CLOSED and do not
> report any SoC revision to avoid confusing users. Use an
> SEC/C abbreviation to avoid growing SOC_NAME_SIZE .
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Igor Opaniuk
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Simon Glass Cc: Simon Glass
> Cc: Tom Rini
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> index afc56b02eea..dd99150fbc2 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> @@ -322,8 +322,23 @@ void get_soc_name(char name[SOC_NAME_SIZE])
>
> get_cpu_string_offsets(, , );
>
> - snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> - soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + if (bsec_dbgswenable()) {
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> + soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + } else {
> + /*
> + * SoC revision is only accessible via DBUMCU IDC register,
> + * which requires BSEC.DENABLE DBGSWENABLE bit to be set to
> + * make the register accessible, otherwise an access to the
> + * register triggers bus fault. As BSEC.DBGSWENABLE is zero
> + * in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
> + * bit as this might open a brief window for timing attacks.
> + * Instead, report that this system is OTP-CLOSED and do not
> + * report any SoC revision to avoid confusing users.
> + */
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s SEC/C",
> + soc_type[type], soc_pkg[pkg]);
> + }
> }
>
> static void setup_soc_type_pkg_rev(void)
Applied on u-boot-stm32/master
Re: [PATCH v2 11/11] net: dwc_eth_qos: Add support for st, ext-phyclk property
On 4/8/24 17:52, Christophe ROULLIER wrote: >> -Original Message- >> From: Marek Vasut >> Sent: Tuesday, March 26, 2024 1:08 PM >> To:u-boot@lists.denx.de >> Cc: Marek Vasut; Christophe >> ROULLIER; Joe >> Hershberger; Patrice CHOTARD - >> foss; Patrick DELAUNAY - >> foss; Ramon >> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com >> Subject: [PATCH v2 11/11] net: dwc_eth_qos: Add support for st,ext-phyclk >> property >> >> The "st,ext-phyclk" property is a unification of "st,eth-clk-sel" >> and "st,eth-ref-clk-sel" properties. All three properties define ETH CK >> clock direction, however: >> - "st,eth-clk-sel" selects clock direction for GMII/RGMII mode >> - "st,eth-ref-clk-sel" selects clock direction for RMII mode >> - "st,ext-phyclk" selects clock direction for all RMII/GMII/RGMII modes The >> "st,ext-phyclk" is the preferrable property to use. >> >> Signed-off-by: Marek Vasut >> --- >> Cc: Christophe Roullier >> Cc: Joe Hershberger >> Cc: Patrice Chotard >> Cc: Patrick Delaunay >> Cc: Ramon Fried >> Cc:u-b...@dh-electronics.com >> Cc:uboot-st...@st-md-mailman.stormreply.com >> --- >> V2: New patch >> --- >> drivers/net/dwc_eth_qos_stm32.c | 30 +++--- >> 1 file changed, 27 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/dwc_eth_qos_stm32.c >> b/drivers/net/dwc_eth_qos_stm32.c index 435473f99a6..9ee82b54c62 100644 >> --- a/drivers/net/dwc_eth_qos_stm32.c >> +++ b/drivers/net/dwc_eth_qos_stm32.c >> @@ -140,6 +140,8 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> const bool is_mp13 = device_is_compatible(dev, >> "st,stm32mp13-dwmac"); >> /* Gigabit Ethernet 125MHz clock selection. */ >> const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel"); >> + /* Ethernet clock source is RCC. */ >> + const bool ext_phyclk = dev_read_bool(dev, "st,ext-phyclk"); >> struct regmap *regmap; >> u32 regmap_mask; >> u32 value; >> @@ -156,6 +158,12 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); >> + /* >> + * STM32MP15xx supports both MII and GMII, STM32MP13xx MII >> only. >> + * SYSCFG_PMCSETR ETH_SELMII is present only on STM32MP15xx >> and >> + * acts as a selector between 0:GMII and 1:MII. As >> STM32MP13xx >> + * supports only MII, ETH_SELMII is not present. >> + */ >> if (!is_mp13) /* Select MII mode on STM32MP15xx */ >> value |= SYSCFG_PMCSETR_ETH_SELMII; >> break; >> @@ -163,14 +171,25 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); >> - if (eth_clk_sel) >> + /* >> + * If eth_clk_sel is set, use internal ETH_CLKx clock from >> RCC, >> + * otherwise use external clock from IO pin (requires >> matching >> + * GPIO block AF setting of that pin). >> + */ >> + if (eth_clk_sel || ext_phyclk) >> value |= SYSCFG_PMCSETR_ETH_CLK_SEL; >> break; >> case PHY_INTERFACE_MODE_RMII: >> dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_RMII); >> - if (eth_ref_clk_sel) >> + /* >> + * If eth_ref_clk_sel is set, use internal clock from RCC, >> + * otherwise use external clock from ETHn_RX_CLK/ETHn_REF_CLK >> + * IO pin (requires matching GPIO block AF setting of that >> + * pin). >> + */ >> + if (eth_ref_clk_sel || ext_phyclk) >> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL; >>
Re: [PATCH v2 09/11] net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform
On 4/8/24 17:50, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Marek
>> Vasut; Joe Hershberger; Patrice
>> CHOTARD - foss; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 09/11] net: dwc_eth_qos: Add DT parsing for STM32MP13xx
>> platform
>>
>> From: Christophe Roullier
>>
>> Manage 2 ethernet instances, select which instance to configure with mask If
>> mask is not present in DT, it is stm32mp15 platform.
>>
>> Signed-off-by: Christophe Roullier
>> Signed-off-by: Marek Vasut # Rework the code
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: - Drop unrelated clock frequency validation
>> - Move "st,ext-phyclk" property support into separate patch
>> - This leaves only the regmap parts here
>> ---
>> drivers/net/dwc_eth_qos_stm32.c | 41 ++---
>> 1 file changed, 28 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 0b13d01346b..5a20fe5bea2 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -33,11 +34,16 @@
>>
>> /* SYSCFG registers */
>> #define SYSCFG_PMCSETR 0x04
>> -#define SYSCFG_PMCCLRR 0x44
>> +#define SYSCFG_PMCCLRR_MP13 0x08
>> +#define SYSCFG_PMCCLRR_MP15 0x44
>> +
>> +#define SYSCFG_PMCSETR_ETH1_MASK GENMASK(23, 16)
>> +#define SYSCFG_PMCSETR_ETH2_MASK GENMASK(31, 24)
>>
>> #define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
>> #define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
>>
>> +/* STM32MP15xx specific bit */
>> #define SYSCFG_PMCSETR_ETH_SELMII BIT(20)
>>
>> #define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
>> @@ -130,23 +136,30 @@ static int eqos_probe_syscfg_stm32(struct udevice
>> *dev, {
>> /* Ethernet 50MHz RMII clock selection. */
>> const bool eth_ref_clk_sel = dev_read_bool(dev,
>> "st,eth-ref-clk-sel");
>> + /* SoC is STM32MP13xx with two ethernet MACs */
>> + const bool is_mp13 = device_is_compatible(dev, "st,stm32mp13-dwmac");
>> /* Gigabit Ethernet 125MHz clock selection. */
>> const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
>> - u8 *syscfg;
>> + struct regmap *regmap;
>> + u32 regmap_mask;
>> u32 value;
>>
>> - syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
>> - if (!syscfg)
>> - return -ENODEV;
>> + regmap = syscon_regmap_lookup_by_phandle(dev, "st,syscon");
>> + if (IS_ERR(regmap))
>> + return PTR_ERR(regmap);
>> +
>> + regmap_mask = dev_read_u32_index_default(dev, "st,syscon", 2,
>> + SYSCFG_PMCSETR_ETH1_MASK);
>>
>> switch (interface_type) {
>> case PHY_INTERFACE_MODE_MII:
>> dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
>> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
>> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
>> - value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
>> + if (!is_mp13) /* Select MII mode on STM32MP15xx */
>> + value |= SYSCFG_PMCSETR_ETH_SELMII;
>> break;
>> - case PHY_INTERFACE_MODE_GMII:
>> + case PHY_INTERFACE_MODE_GMII: /* STM32MP15xx only */
>> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
>> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
>> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); @@
>> -177,13 +190,15 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>> return -EINVAL;
>> }
>>
>> - /* clear and set ETH configuration bits */
>> - writel
Re: [PATCH v2 08/11] net: dwc_eth_qos: Constify st,eth-* values parsed out of DT
On 3/26/24 13:07, Marek Vasut wrote:
> Use const bool for the values parsed out of DT. Drop the duplicate
> assignment of false into those bool variables, assign them directly
> with the content parsed out of DT. Abbreviate the variable name too.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: - Add RB from Patrice
> - Add trailing fullstop at the end of code comment
> ---
> drivers/net/dwc_eth_qos_stm32.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 72f65f80540..0b13d01346b 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -128,17 +128,13 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
> static int eqos_probe_syscfg_stm32(struct udevice *dev,
> phy_interface_t interface_type)
> {
> - bool eth_ref_clk_sel_reg = false;
> - bool eth_clk_sel_reg = false;
> + /* Ethernet 50MHz RMII clock selection. */
> + const bool eth_ref_clk_sel = dev_read_bool(dev, "st,eth-ref-clk-sel");
> + /* Gigabit Ethernet 125MHz clock selection. */
> + const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
> u8 *syscfg;
> u32 value;
>
> - /* Gigabit Ethernet 125MHz clock selection. */
> - eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
> -
> - /* Ethernet 50Mhz RMII clock selection */
> - eth_ref_clk_sel_reg = dev_read_bool(dev, "st,eth-ref-clk-sel");
> -
> syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
> if (!syscfg)
> return -ENODEV;
> @@ -154,14 +150,14 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> - if (eth_clk_sel_reg)
> + if (eth_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RMII:
> dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> - if (eth_ref_clk_sel_reg)
> + if (eth_ref_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RGMII:
> @@ -171,7 +167,7 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RGMII);
> - if (eth_clk_sel_reg)
> + if (eth_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> default:
Applied on u-boot-stm32/master
Re: [PATCH v2 10/11] net: dwc_eth_qos: Add support of STM32MP13xx platform
On 4/8/24 17:51, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Patrice CHOTARD -
>> foss; Marek Vasut; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 10/11] net: dwc_eth_qos: Add support of STM32MP13xx
>> platform
>>
>> From: Christophe Roullier
>>
>> Add compatible "st,stm32mp13-dwmac" to manage STM32MP13 boards.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Christophe Roullier
>> Signed-off-by: Marek Vasut # Rebase, reshuffle, squash code
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos.c | 4
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 11 +++
>> 3 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 203bfc0848c..e02317905e5 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -1505,6 +1505,10 @@ static const struct udevice_id eqos_ids[] = {
>> },
>> #endif
>> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
>> + {
>> + .compatible = "st,stm32mp13-dwmac",
>> + .data = (ulong)_stm32mp13_config
>> + },
>> {
>> .compatible = "st,stm32mp1-dwmac",
>> .data = (ulong)_stm32mp15_config diff --git
>> a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h index
>> bafd0d339fb..8b3d0d464d3 100644
>> --- a/drivers/net/dwc_eth_qos.h
>> +++ b/drivers/net/dwc_eth_qos.h
>> @@ -290,5 +290,6 @@ int eqos_null_ops(struct udevice *dev); extern struct
>> eqos_config eqos_imx_config; extern struct eqos_config
>> eqos_rockchip_config; extern struct eqos_config eqos_qcom_config;
>> +extern struct eqos_config eqos_stm32mp13_config;
>> extern struct eqos_config eqos_stm32mp15_config; extern struct
>> eqos_config eqos_jh7110_config; diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 5a20fe5bea2..435473f99a6 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -279,6 +279,17 @@ static struct eqos_ops eqos_stm32_ops = {
>> .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32 };
>>
>> +struct eqos_config __maybe_unused eqos_stm32mp13_config = {
>> + .reg_access_always_ok = false,
>> + .mdio_wait = 1,
>> + .swr_wait = 50,
>> + .config_mac = EQOS_MAC_RXQ_CTRL0_RXQ0EN_ENABLED_DCB,
>> + .config_mac_mdio = EQOS_MAC_MDIO_ADDRESS_CR_250_300,
>> + .axi_bus_width = EQOS_AXI_WIDTH_32,
>> + .interface = dev_read_phy_mode,
>> + .ops = _stm32_ops
>> +};
>> +
>> struct eqos_config __maybe_unused eqos_stm32mp15_config = {
>> .reg_access_always_ok = false,
>> .mdio_wait = 1,
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 07/11] net: dwc_eth_qos: Use consistent logging prints
On 3/26/24 13:07, Marek Vasut wrote:
> Use dev_*() only to print all the logs from this glue code,
> instead of mixing dev_*(), log_*(), pr_*() all in one code.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 52 ++---
> 1 file changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 38037c47954..72f65f80540 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -63,36 +63,36 @@ static int eqos_start_clks_stm32(struct udevice *dev)
> if (!CONFIG_IS_ENABLED(CLK))
> return 0;
>
> - debug("%s(dev=%p):\n", __func__, dev);
> + dev_dbg(dev, "%s:\n", __func__);
>
> ret = clk_enable(>clk_master_bus);
> if (ret < 0) {
> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_master_bus) failed: %d\n", ret);
> goto err;
> }
>
> ret = clk_enable(>clk_rx);
> if (ret < 0) {
> - pr_err("clk_enable(clk_rx) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_rx) failed: %d\n", ret);
> goto err_disable_clk_master_bus;
> }
>
> ret = clk_enable(>clk_tx);
> if (ret < 0) {
> - pr_err("clk_enable(clk_tx) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_tx) failed: %d\n", ret);
> goto err_disable_clk_rx;
> }
>
> if (clk_valid(>clk_ck) && !eqos->clk_ck_enabled) {
> ret = clk_enable(>clk_ck);
> if (ret < 0) {
> - pr_err("clk_enable(clk_ck) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_ck) failed: %d\n", ret);
> goto err_disable_clk_tx;
> }
> eqos->clk_ck_enabled = true;
> }
>
> - debug("%s: OK\n", __func__);
> + dev_dbg(dev, "%s: OK\n", __func__);
> return 0;
>
> err_disable_clk_tx:
> @@ -102,7 +102,8 @@ err_disable_clk_rx:
> err_disable_clk_master_bus:
> clk_disable(>clk_master_bus);
> err:
> - debug("%s: FAILED: %d\n", __func__, ret);
> + dev_dbg(dev, "%s: FAILED: %d\n", __func__, ret);
> +
> return ret;
> }
>
> @@ -113,13 +114,14 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
> if (!CONFIG_IS_ENABLED(CLK))
> return 0;
>
> - debug("%s(dev=%p):\n", __func__, dev);
> + dev_dbg(dev, "%s:\n", __func__);
>
> clk_disable(>clk_tx);
> clk_disable(>clk_rx);
> clk_disable(>clk_master_bus);
>
> - debug("%s: OK\n", __func__);
> + dev_dbg(dev, "%s: OK\n", __func__);
> +
> return 0;
> }
>
> @@ -143,20 +145,20 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> - log_debug("PHY_INTERFACE_MODE_MII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_GMII:
> - log_debug("PHY_INTERFACE_MODE_GMII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RMII:
> - log_debug("PHY_INTERFACE_MODE_RMII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> @@ -166,15 +168,15 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> case PHY_INTERFA
Re: [PATCH v2 06/11] net: dwc_eth_qos: Move log_debug statements on top of case block
On 3/26/24 13:07, Marek Vasut wrote:
> Move the log_debug() calls on top of the bit manipulation code.
> No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 7545026b158..38037c47954 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -143,34 +143,34 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> + log_debug("PHY_INTERFACE_MODE_MII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_MII\n");
> break;
> case PHY_INTERFACE_MODE_GMII:
> + log_debug("PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_GMII\n");
> break;
> case PHY_INTERFACE_MODE_RMII:
> + log_debug("PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_RMII\n");
> break;
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> + log_debug("PHY_INTERFACE_MODE_RGMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RGMII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_RGMII\n");
> break;
> default:
> log_debug("Do not manage %d interface\n",
Applied on u-boot-stm32/master
Re: [PATCH v2 05/11] net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield
On 3/26/24 13:07, Marek Vasut wrote:
> Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR
> register. No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index d7ec0c9be36..7545026b158 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "dwc_eth_qos.h"
> @@ -40,9 +41,9 @@
> #define SYSCFG_PMCSETR_ETH_SELMIIBIT(20)
>
> #define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
> -#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0
> -#define SYSCFG_PMCSETR_ETH_SEL_RGMII BIT(21)
> -#define SYSCFG_PMCSETR_ETH_SEL_RMII BIT(23)
> +#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0x0
> +#define SYSCFG_PMCSETR_ETH_SEL_RGMII 0x1
> +#define SYSCFG_PMCSETR_ETH_SEL_RMII 0x4
>
> static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
> {
> @@ -142,35 +143,33 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> + value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_MII\n");
> break;
> case PHY_INTERFACE_MODE_GMII:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
> + value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_GMII\n");
> break;
> case PHY_INTERFACE_MODE_RMII:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII;
> + value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_RMII\n");
> break;
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_RGMII);
> if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
> + value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_RGMII\n");
> break;
> default:
Applied on u-boot-stm32/master
Re: [PATCH v2 04/11] net: dwc_eth_qos: Scrub ifdeffery
On 4/8/24 09:27, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To: u-boot@lists.denx.de
>> Cc: Marek Vasut ; Patrice CHOTARD - foss
>> ; Christophe ROULLIER
>> ; Joe Hershberger ;
>> Patrick DELAUNAY - foss ; Ramon Fried
>> ; u-b...@dh-electronics.com;
>> uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 04/11] net: dwc_eth_qos: Scrub ifdeffery
>>
>> Replace ifdef CONFIG_CLK with if (CONFIG_IS_ENABLED(CLK)) to improve code
>> build coverage. Some of the functions printed debug("%s: OK\n", __func__);
>> on exit with and without CLK enabled, some did not, make it consistent and
>> print nothing if CLK is disabled.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc: u-b...@dh-electronics.com
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos_stm32.c | 25 -
>> 1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 7520a136ed0..d7ec0c9be36 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -46,21 +46,22 @@
>>
>> static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev) { -#ifdef
>> CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> +
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>>
>> return clk_get_rate(>clk_master_bus);
>> -#else
>> - return 0;
>> -#endif
>> }
>>
>> static int eqos_start_clks_stm32(struct udevice *dev) { -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> int ret;
>>
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>> +
>> debug("%s(dev=%p):\n", __func__, dev);
>>
>> ret = clk_enable(>clk_master_bus);
>> @@ -89,12 +90,10 @@ static int eqos_start_clks_stm32(struct udevice *dev)
>> }
>> eqos->clk_ck_enabled = true;
>> }
>> -#endif
>>
>> debug("%s: OK\n", __func__);
>> return 0;
>>
>> -#ifdef CONFIG_CLK
>> err_disable_clk_tx:
>> clk_disable(>clk_tx);
>> err_disable_clk_rx:
>> @@ -104,20 +103,20 @@ err_disable_clk_master_bus:
>> err:
>> debug("%s: FAILED: %d\n", __func__, ret);
>> return ret;
>> -#endif
>> }
>>
>> static int eqos_stop_clks_stm32(struct udevice *dev) { -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> +
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>>
>> debug("%s(dev=%p):\n", __func__, dev);
>>
>> clk_disable(>clk_tx);
>> clk_disable(>clk_rx);
>> clk_disable(>clk_master_bus);
>> -#endif
>>
>> debug("%s: OK\n", __func__);
>> return 0;
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 03/11] net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code
On 3/26/24 13:07, Marek Vasut wrote:
> Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32
> driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT
> properties of this MAC and configures SYSCFG registers accordingly, there
> is nothing board specific happening in this function, move it into generic
> driver code instead. Drop the now unused duplicates from board files.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> board/dhelectronics/dh_stm32mp1/board.c | 82 ---
> board/st/stm32mp1/stm32mp1.c| 82 ---
> drivers/net/dwc_eth_qos_stm32.c | 86 -
> 3 files changed, 84 insertions(+), 166 deletions(-)
>
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c
> b/board/dhelectronics/dh_stm32mp1/board.c
> index d1f662d9701..f179c857116 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -48,12 +48,10 @@
>
> /* SYSCFG registers */
> #define SYSCFG_BOOTR 0x00
> -#define SYSCFG_PMCSETR 0x04
> #define SYSCFG_IOCTRLSETR0x18
> #define SYSCFG_ICNR 0x1C
> #define SYSCFG_CMPCR 0x20
> #define SYSCFG_CMPENSETR 0x24
> -#define SYSCFG_PMCCLRR 0x44
>
> #define SYSCFG_BOOTR_BOOT_MASK GENMASK(2, 0)
> #define SYSCFG_BOOTR_BOOTPD_SHIFT4
> @@ -69,16 +67,6 @@
>
> #define SYSCFG_CMPENSETR_MPU_EN BIT(0)
>
> -#define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
> -#define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
> -
> -#define SYSCFG_PMCSETR_ETH_SELMIIBIT(20)
> -
> -#define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
> -#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0
> -#define SYSCFG_PMCSETR_ETH_SEL_RGMII BIT(21)
> -#define SYSCFG_PMCSETR_ETH_SEL_RMII BIT(23)
> -
> #define KS_CCR 0x08
> #define KS_CCR_EEPROMBIT(9)
> #define KS_BE0 BIT(12)
> @@ -679,76 +667,6 @@ void board_quiesce_devices(void)
> #endif
> }
>
> -/* eth init function : weak called in eqos driver */
> -int board_interface_eth_init(struct udevice *dev,
> - phy_interface_t interface_type)
> -{
> - u8 *syscfg;
> - u32 value;
> - bool eth_clk_sel_reg = false;
> - bool eth_ref_clk_sel_reg = false;
> -
> - /* Gigabit Ethernet 125MHz clock selection. */
> - eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
> -
> - /* Ethernet 50Mhz RMII clock selection */
> - eth_ref_clk_sel_reg =
> - dev_read_bool(dev, "st,eth-ref-clk-sel");
> -
> - syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
> -
> - if (!syscfg)
> - return -ENODEV;
> -
> - switch (interface_type) {
> - case PHY_INTERFACE_MODE_MII:
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - debug("%s: PHY_INTERFACE_MODE_MII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_GMII:
> - if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
> - debug("%s: PHY_INTERFACE_MODE_GMII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_RMII:
> - if (eth_ref_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII;
> - debug("%s: PHY_INTERFACE_MODE_RMII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_RGMII:
> - case PHY_INTERFACE_MODE_RGMII_ID:
> - case PHY_INTERFACE_MODE_RGMII_RXID:
> - case PHY_INTERFACE_MODE_RGMII_TXID:
> - if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
> - debug("%s: PHY_INTERFACE_MODE_RGMII\n", __func__);
> - break;
> - default:
> - debug("
Re: [PATCH v2 02/11] net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config
On 4/8/24 09:26, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 02/11] net: dwc_eth_qos: Rename eqos_stm32_config to
>> eqos_stm32mp15_config
>>
>> The current glue code is specific to STM32MP15xx, the upcoming STM32MP13xx
>> will introduce another entry specific to the STM32MP13xx. Rename the current
>> entry to eqos_stm32mp15_config in preparation for STM32MP13xx addition. No
>> functional change.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos.c | 2 +-
>> drivers/net/dwc_eth_qos.h | 2 +-
>> drivers/net/dwc_eth_qos_stm32.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 533c2bf070b..203bfc0848c 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -1507,7 +1507,7 @@ static const struct udevice_id eqos_ids[] = { #if
>> IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
>> {
>> .compatible = "st,stm32mp1-dwmac",
>> - .data = (ulong)_stm32_config
>> + .data = (ulong)_stm32mp15_config
>> },
>> #endif
>> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX)
>> diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h index
>> a6087f191ab..bafd0d339fb 100644
>> --- a/drivers/net/dwc_eth_qos.h
>> +++ b/drivers/net/dwc_eth_qos.h
>> @@ -290,5 +290,5 @@ int eqos_null_ops(struct udevice *dev); extern struct
>> eqos_config eqos_imx_config; extern struct eqos_config
>> eqos_rockchip_config; extern struct eqos_config eqos_qcom_config; -extern
>> struct eqos_config eqos_stm32_config;
>> +extern struct eqos_config eqos_stm32mp15_config;
>> extern struct eqos_config eqos_jh7110_config; diff --git
>> a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c index
>> cfda757133e..fd29a604987 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -184,7 +184,7 @@ static struct eqos_ops eqos_stm32_ops = {
>> .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32 };
>>
>> -struct eqos_config __maybe_unused eqos_stm32_config = {
>> +struct eqos_config __maybe_unused eqos_stm32mp15_config = {
>> .reg_access_always_ok = false,
>> .mdio_wait = 1,
>> .swr_wait = 50,
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate file
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate
>> file
>>
>> Move STM32 glue code into separate file to contain the STM32 specific code
>> outside of the DWMAC core code. No functional change.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/Makefile | 1 +
>> drivers/net/dwc_eth_qos.c | 165 ---
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 196
>> 4 files changed, 198 insertions(+), 165 deletions(-) create mode 100644
>> drivers/net/dwc_eth_qos_stm32.c
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile index
>> 6677366ebd6..dc3404519d6 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
>> obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
>> obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
>> obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
>> +obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
>> obj-$(CONFIG_E1000) += e1000.o
>> obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>> obj-$(CONFIG_EEPRO100) += eepro100.o
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 9b3bce1dc87..533c2bf070b 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -295,58 +295,6 @@ err:
>> #endif
>> }
>>
>> -static int eqos_start_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> - int ret;
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - ret = clk_enable(>clk_master_bus);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
>> - goto err;
>> - }
>> -
>> - ret = clk_enable(>clk_rx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_rx) failed: %d", ret);
>> - goto err_disable_clk_master_bus;
>> - }
>> -
>> - ret = clk_enable(>clk_tx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_tx) failed: %d", ret);
>> - goto err_disable_clk_rx;
>> - }
>> -
>> - if (clk_valid(>clk_ck) && !eqos->clk_ck_enabled) {
>> - ret = clk_enable(>clk_ck);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_ck) failed: %d", ret);
>> - goto err_disable_clk_tx;
>> - }
>> - eqos->clk_ck_enabled = true;
>> - }
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -
>> -#ifdef CONFIG_CLK
>> -err_disable_clk_tx:
>> - clk_disable(>clk_tx);
>> -err_disable_clk_rx:
>> - clk_disable(>clk_rx);
>> -err_disable_clk_master_bus:
>> - clk_disable(>clk_master_bus);
>> -err:
>> - debug("%s: FAILED: %d\n", __func__, ret);
>> - return ret;
>> -#endif
>> -}
>> -
>> static int eqos_stop_clks_tegra186(struct udevice *dev) { #ifdef
>> CONFIG_CLK @@ -365,22 +313,6 @@ static int eqos_stop_clks_tegra186(struct
>> udevice *dev)
>> return 0;
>> }
>>
>> -static int eqos_stop_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - clk_disable(>clk_tx);
>> - clk_disable(>clk_rx);
>> - clk_disable(>clk_master_
Re: [Uboot-stm32] [PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/19/24 11:36, Patrice CHOTARD wrote: > > > On 4/19/24 05:59, Marek Vasut wrote: >> In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be >> released from endless loop in BootROM only by populating TAMP BKPxR 4 >> and 5 with magic and branch address and sending SGI0 interrupt from >> core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized >> as well to release the core 1 from endless loop during the second SGI0 >> handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup >> registers, the ones which contain the core 1 magic, branch address and >> boot information. >> >> This requirement seems to be undocumented, therefore it was necessary >> to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. >> Ultimately, it turns out that a certain BootROM function reads out the >> TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. >> If they are zero, the BootROM code again waits for SGI0 using WFI, else >> the execution moves forward until it reaches handoff to the TAMP BKPxR 5 >> branch address. >> >> This fixes CPU core 1 release using U-Boot PSCI implementation on an >> OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. >> >> Reviewed-by: Patrick Delaunay >> Signed-off-by: Marek Vasut >> --- >> Cc: Igor Opaniuk >> Cc: Patrice Chotard >> Cc: Patrick Delaunay >> Cc: Simon Glass > Cc: Simon Glass >> Cc: Tom Rini >> Cc: u-b...@dh-electronics.com >> Cc: uboot-st...@st-md-mailman.stormreply.com >> --- >> V2: Fix up the BKPRWD/BKPWD mask typo >> V3: - Update the allocation to 0x20/0x20 >> - Update commit message >> - Add RB from Patrick >> --- >> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> index dd99150fbc2..d75ec99d6a1 100644 >> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> @@ -14,6 +14,7 @@ >> #include >> #include >> #include >> +#include >> >> /* RCC register */ >> #define RCC_TZCR(STM32_RCC_BASE + 0x00) >> @@ -41,6 +42,9 @@ >> #define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114) >> >> #define TAMP_CR1(STM32_TAMP_BASE + 0x00) >> +#define TAMP_SMCR (STM32_TAMP_BASE + 0x20) >> +#define TAMP_SMCR_BKPRWDPROTGENMASK(7, 0) >> +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) >> >> #define PWR_CR1 (STM32_PWR_BASE + 0x00) >> #define PWR_MCUCR (STM32_PWR_BASE + 0x14) >> @@ -136,6 +140,18 @@ static void security_init(void) >> */ >> writel(0x0, TAMP_CR1); >> >> +/* >> + * TAMP: Configure non-zero secure protection settings. This is >> + * checked by BootROM function 35ac on OTP-CLOSED device during >> + * CPU core 1 release from endless loop. If secure protection >> + * fields are zero, the core 1 is not released from endless >> + * loop on second SGI0. >> + */ >> +clrsetbits_le32(TAMP_SMCR, >> +TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT, >> +FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) | >> +FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20)); >> + >> /* GPIOZ: deactivate the security */ >> writel(BIT(0), RCC_MP_AHB5ENSETR); >> writel(0x0, GPIOZ_SECCFGR); > Hi Marek > > Reviewed-by: Patrice Chotard Applied on u-boot-stm32/master > > Thanks > Patrice > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate file
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate
>> file
>>
>> Move STM32 glue code into separate file to contain the STM32 specific code
>> outside of the DWMAC core code. No functional change.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/Makefile | 1 +
>> drivers/net/dwc_eth_qos.c | 165 ---
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 196
>> 4 files changed, 198 insertions(+), 165 deletions(-) create mode 100644
>> drivers/net/dwc_eth_qos_stm32.c
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile index
>> 6677366ebd6..dc3404519d6 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
>> obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
>> obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
>> obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
>> +obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
>> obj-$(CONFIG_E1000) += e1000.o
>> obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>> obj-$(CONFIG_EEPRO100) += eepro100.o
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 9b3bce1dc87..533c2bf070b 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -295,58 +295,6 @@ err:
>> #endif
>> }
>>
>> -static int eqos_start_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> - int ret;
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - ret = clk_enable(>clk_master_bus);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
>> - goto err;
>> - }
>> -
>> - ret = clk_enable(>clk_rx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_rx) failed: %d", ret);
>> - goto err_disable_clk_master_bus;
>> - }
>> -
>> - ret = clk_enable(>clk_tx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_tx) failed: %d", ret);
>> - goto err_disable_clk_rx;
>> - }
>> -
>> - if (clk_valid(>clk_ck) && !eqos->clk_ck_enabled) {
>> - ret = clk_enable(>clk_ck);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_ck) failed: %d", ret);
>> - goto err_disable_clk_tx;
>> - }
>> - eqos->clk_ck_enabled = true;
>> - }
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -
>> -#ifdef CONFIG_CLK
>> -err_disable_clk_tx:
>> - clk_disable(>clk_tx);
>> -err_disable_clk_rx:
>> - clk_disable(>clk_rx);
>> -err_disable_clk_master_bus:
>> - clk_disable(>clk_master_bus);
>> -err:
>> - debug("%s: FAILED: %d\n", __func__, ret);
>> - return ret;
>> -#endif
>> -}
>> -
>> static int eqos_stop_clks_tegra186(struct udevice *dev) { #ifdef
>> CONFIG_CLK @@ -365,22 +313,6 @@ static int eqos_stop_clks_tegra186(struct
>> udevice *dev)
>> return 0;
>> }
>>
>> -static int eqos_stop_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - clk_disable(>clk_tx);
>> - clk_disable(>clk_rx);
>> - clk_disable(>clk_master_
[PULL] Pull request for u-boot master / v2024.07 = u-boot-stm32-20240419
Hi Tom Please pull the STM32 related patches for u-boot/master, v2024.07: u-boot-stm32-20240419 CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/20430 The following changes since commit 97b34f6ace539c9c16eb8565f8b58730848ba97a: env: mmc: print MMC device being read (2024-04-18 16:37:25 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20240419 for you to fetch changes up to b0283b5e3d37daff48b45c3f98d298844603def4: ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot (2024-04-19 12:05:10 +0200) MP1: _ Add OHCI HCD support for STM32MP15xx DHSOM _ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx _ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx _ Jump to ep on successful resume in PSCI suspend code _ Add FASTBOOT support for STM32MP13 _ Fix/Rework key and leds management for STM32MP13/15 _ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support MP2: _ Add stm32-fmc-ebi support _ Add: sdmmc2 support and fix AARCH64 compilation Christophe Kerello (3): memory: stm32-fmc2-ebi: add MP25 support memory: stm32-fmc2-ebi: add MP25 RIF support mtd: rawnand: stm32_fmc2: add MP25 support Christophe Roullier (2): net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform net: dwc_eth_qos: Add support of STM32MP13xx platform Marek Vasut (14): arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM net: dwc_eth_qos: Split STM32 glue into separate file net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code net: dwc_eth_qos: Scrub ifdeffery net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield net: dwc_eth_qos: Move log_debug statements on top of case block net: dwc_eth_qos: Use consistent logging prints net: dwc_eth_qos: Constify st, eth-* values parsed out of DT net: dwc_eth_qos: Add support for st, ext-phyclk property ARM: stm32: Jump to ep on successful resume in PSCI suspend code ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx Patrice Chotard (29): ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings configs: stm32mp13: Enable FASTBOOT configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check() ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot Patrick Delaunay (2): stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 19 +- arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 34 +++---
Re: [PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/19/24 05:59, Marek Vasut wrote: > In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be > released from endless loop in BootROM only by populating TAMP BKPxR 4 > and 5 with magic and branch address and sending SGI0 interrupt from > core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized > as well to release the core 1 from endless loop during the second SGI0 > handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup > registers, the ones which contain the core 1 magic, branch address and > boot information. > > This requirement seems to be undocumented, therefore it was necessary > to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. > Ultimately, it turns out that a certain BootROM function reads out the > TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. > If they are zero, the BootROM code again waits for SGI0 using WFI, else > the execution moves forward until it reaches handoff to the TAMP BKPxR 5 > branch address. > > This fixes CPU core 1 release using U-Boot PSCI implementation on an > OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. > > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > V2: Fix up the BKPRWD/BKPWD mask typo > V3: - Update the allocation to 0x20/0x20 > - Update commit message > - Add RB from Patrick > --- > arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > index dd99150fbc2..d75ec99d6a1 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > /* RCC register */ > #define RCC_TZCR (STM32_RCC_BASE + 0x00) > @@ -41,6 +42,9 @@ > #define TZC_REGION_ID_ACCESS0(STM32_TZC_BASE + 0x114) > > #define TAMP_CR1 (STM32_TAMP_BASE + 0x00) > +#define TAMP_SMCR(STM32_TAMP_BASE + 0x20) > +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0) > +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) > > #define PWR_CR1 (STM32_PWR_BASE + 0x00) > #define PWR_MCUCR(STM32_PWR_BASE + 0x14) > @@ -136,6 +140,18 @@ static void security_init(void) >*/ > writel(0x0, TAMP_CR1); > > + /* > + * TAMP: Configure non-zero secure protection settings. This is > + * checked by BootROM function 35ac on OTP-CLOSED device during > + * CPU core 1 release from endless loop. If secure protection > + * fields are zero, the core 1 is not released from endless > + * loop on second SGI0. > + */ > + clrsetbits_le32(TAMP_SMCR, > + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT, > + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) | > + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20)); > + > /* GPIOZ: deactivate the security */ > writel(BIT(0), RCC_MP_AHB5ENSETR); > writel(0x0, GPIOZ_SECCFGR); Hi Marek Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH] stm32mp: Reserve OPTEE area in EFI memory map
On 4/17/24 09:45, Heinrich Schuchardt wrote:
> On 17.04.24 09:25, Patrick DELAUNAY wrote:
>> Hi,
>>
>> On 3/8/24 11:12, Patrice Chotard wrote:
>>> Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
>>> memory region above ram_top is tagged in EFI memory map as
>>> EFI_BOOT_SERVICES_DATA.
>>> In case of STM32MP1 platform, above ram_top, there is one reserved-memory
>>> region tagged "no-map" dedicated to OP-TEE (addr=de00 size=200).
>>>
>>> Before booting kernel, EFI memory map is first built, the OPTEE region is
>>> tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
>>> is used.
>>>
>>> Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
>>> which try to add again the same OPTEE region (addr=de00 size=200)
>>> but now with LMB_NOMAP tag which produces the following error message :
>>>
>>> "ERROR: reserving fdt memory region failed (addr=de00 size=200
>>> flags=4)"
>>>
>>> To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
>>> it as reserved.
>>>
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> arch/arm/mach-stm32mp/dram_init.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-stm32mp/dram_init.c
>>> b/arch/arm/mach-stm32mp/dram_init.c
>>> index fb1208fc5d5..f67f54f2ae0 100644
>>> --- a/arch/arm/mach-stm32mp/dram_init.c
>>> +++ b/arch/arm/mach-stm32mp/dram_init.c
>>> @@ -7,6 +7,7 @@
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
>>> total_size)
>>> return reg + size;
>>> }
>>> +
>>> +void efi_add_known_memory(void)
>>> +{
>>> + if (IS_ENABLED(CONFIG_EFI_LOADER))
>>> + /*
>>> + * Memory over ram_top is reserved to OPTEE.
>>> + * Declare to EFI only memory area below ram_top
>>> + */
>>> + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
>>> + EFI_CONVENTIONAL_MEMORY);
>
> With this change the EFI memory map passed to the operating system will
> not contain any memory above gd->ram_top. Is this really your intent?
> Don't you have any memory above 0xe000?
Hi Heinrich
On stm32mp157x-dk and stm32mp135x-dk boards, there is no memory above
0xe000.
But, on stm32mp157x-ed1 or stm32mp157x-ev1, you are right, we got memory above
0xe000.
I will rework this patch to take into account memory that could be present
above OPTEE area.
Thanks for pointing this
Patrice
>
> Best regards
>
> Heinrich
>
>>> +}
>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>>
>> Thanks
>> Patrick
>>
>
Re: [PATCH v2 00/11] net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
On 4/17/24 18:47, Marek Vasut wrote: > On 3/26/24 1:07 PM, Marek Vasut wrote: >> Split off STM32 glue code from the DWMAC driver into separate >> file, similar to what other SoCs already do, to avoid mixing >> the ST specifics with generic DWMAC core code. >> >> Clean the STM32 DWMAC board code which is currently duplicated >> in multiple board files, move it into the newly separated glue >> code, since the code is not board specific, it is only generic >> DT parsing and generic register programming. >> >> Add STM32MP13xx support based on ST downstream patches on top, >> although that part is mostly rewritten from scratch. > > Can either of you, Patrice/Patrick, pick this series via ST tree and create a > MR for Tom (possibly including the other long outstanding patches too) ? > > Thanks Hi Marek STM32 pull request will be done tomorrow. Patrice
Re: [PATCH] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/14/24 20:39, Marek Vasut wrote: > In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be > released from endless loop in BootROM only by populating TAMP BKPxR 4 > and 5 with magic and branch address and sending SGI0 interrupt from > core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized > as well to release the core 1 from endless loop during the second SGI0 > handling on core 1. Initialize TAMP_SMCR to protect the first 16 backup > registers, the ones which contain the core 1 magic, branch address and > boot information. > > This requirement seems to be undocumented, therefore it was necessary > to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. > Ultimately, it turns out that a certain BootROM function reads out the > TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. > If they are zero, the BootROM code again waits for SGI0 using WFI, else > the execution moves forward until it reaches handoff to the TAMP BKPxR 5 > branch address. > > This fixes CPU core 1 release using U-Boot PSCI implementation on an > OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. > > Signed-off-by: Marek Vasut > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > index dd99150fbc2..138a6d6b614 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > /* RCC register */ > #define RCC_TZCR (STM32_RCC_BASE + 0x00) > @@ -41,6 +42,9 @@ > #define TZC_REGION_ID_ACCESS0(STM32_TZC_BASE + 0x114) > > #define TAMP_CR1 (STM32_TAMP_BASE + 0x00) > +#define TAMP_SMCR(STM32_TAMP_BASE + 0x20) > +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0) > +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) > > #define PWR_CR1 (STM32_PWR_BASE + 0x00) > #define PWR_MCUCR(STM32_PWR_BASE + 0x14) > @@ -136,6 +140,18 @@ static void security_init(void) >*/ > writel(0x0, TAMP_CR1); > > + /* > + * TAMP: Configure non-zero secure protection settings. This is > + * checked by BootROM function 35ac on OTP-CLOSED device during > + * CPU core 1 release from endless loop. If secure protection > + * fields are zero, the core 1 is not released from endless > + * loop on second SGI0. > + */ > + clrsetbits_le32(TAMP_SMCR, > + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPRWDPROT, Hi Marek there is a typo, you used twice TAMP_SMCR_BKPRWDPROT : TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPRWDPROT => TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT ^ Patrice > + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x10) | > + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x10)); > + > /* GPIOZ: deactivate the security */ > writel(BIT(0), RCC_MP_AHB5ENSETR); > writel(0x0, GPIOZ_SECCFGR);
Re: [PATCH] ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
On 4/14/24 20:39, Marek Vasut wrote:
> SoC revision is only accessible via DBUMCU IDC register,
> which requires BSEC.DENABLE DBGSWENABLE bit to be set to
> make the register accessible, otherwise an access to the
> register triggers bus fault. As BSEC.DBGSWENABLE is zero
> in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
> bit as this might open a brief window for timing attacks.
> Instead, report that this system is OTP-CLOSED and do not
> report any SoC revision to avoid confusing users. Use an
> SEC/C abbreviation to avoid growing SOC_NAME_SIZE .
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Igor Opaniuk
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Simon Glass Cc: Simon Glass
> Cc: Tom Rini
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> index afc56b02eea..dd99150fbc2 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> @@ -322,8 +322,23 @@ void get_soc_name(char name[SOC_NAME_SIZE])
>
> get_cpu_string_offsets(, , );
>
> - snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> - soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + if (bsec_dbgswenable()) {
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> + soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + } else {
> + /*
> + * SoC revision is only accessible via DBUMCU IDC register,
> + * which requires BSEC.DENABLE DBGSWENABLE bit to be set to
> + * make the register accessible, otherwise an access to the
> + * register triggers bus fault. As BSEC.DBGSWENABLE is zero
> + * in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
> + * bit as this might open a brief window for timing attacks.
> + * Instead, report that this system is OTP-CLOSED and do not
> + * report any SoC revision to avoid confusing users.
> + */
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s SEC/C",
> + soc_type[type], soc_pkg[pkg]);
> + }
> }
>
> static void setup_soc_type_pkg_rev(void)
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH] ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o
On 4/14/24 20:38, Marek Vasut wrote: > The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not > in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two > Makefile entries in each subdirectory. Drop the bogus one and keep > only the correct one, the one in arch/arm/mach-stm32mp/Makefile . > > Signed-off-by: Marek Vasut > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > arch/arm/mach-stm32mp/stm32mp1/Makefile | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/Makefile > b/arch/arm/mach-stm32mp/stm32mp1/Makefile > index 857148747ef..ebae50f66c9 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/Makefile > +++ b/arch/arm/mach-stm32mp/stm32mp1/Makefile > @@ -8,7 +8,6 @@ obj-y += cpu.o > obj-$(CONFIG_STM32MP13X) += stm32mp13x.o > obj-$(CONFIG_STM32MP15X) += stm32mp15x.o > > -obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o > ifdef CONFIG_SPL_BUILD > obj-y += spl.o > obj-y += tzc400.o Hi Marek Reviewed-by: Patrice Chotard Thanks Patrice
Re: [PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
On 4/14/24 13:10, Kumar, Udit wrote:
> Hello Patrice,
>
> On 4/13/2024 1:54 PM, Patrice CHOTARD wrote:
>>
>> On 4/12/24 17:53, Patrice Chotard wrote:
>>> In case a new region is adjacent to a previous region with
>>> similar flag, this region is merged with its predecessor, but no
>>> check are done if this new added region is overlapping another region
>>> present in lmb (see reserved[3] which overlaps reserved[4]).
>>>
>>> [..]
>>> phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align)
>>> {
>>> return lmb_alloc_base(lmb, size, align, LMB_ALLOC_ANYWHERE);
>>
>> I think this series (v2) is not correct even if now the CI tests are OK.
>> After re-reading carefully the lib_test_lmb_overlapping_reserve() test
>> it appears to me there is a contradiction.
>>
>> It's indicating that "check that calling lmb_reserve with overlapping
>> regions fails"
>>
>> but the very last test of lib_test_lmb_overlapping_reserve() has this
>> comment :
>> /* allocate 3rd region, coalesce with first and overlap with second */
>> and this test allows this overlap case.
>>
>> It's not clear if LMB region can overlap each other or not ?
>
>
> I would say partial overlap and coalescing with before one
>
> May be Below can help
>
> /* allocate 2nd region , This should coalesced all region into one
>
> you will get one region as
>
> Address --- Size
>
> 0x4001 --- 0x3
>
> Next after this /* allocate 2nd region, which should be added as first
> region */
>
> we will have two region like
>
> Address --- Size
>
> (0x4000 -- 0x8000)
>
> (0x4001 --- 0x3)
>
> Now third request comes in
>
> /* allocate 3rd region, coalesce with first and overlap with second */
>
> which is address of 0x40008000 and size of 0x1, Now this region to be
> added
>
> is coalescing with first (0x4000 -- 0x8000) and part of this overlap with
> (0x4001 --- 0x3).
>
> So, what this patch does , merge all these into one region
>
> as (0x4000 -- 0x4)
Hi Udit
Ok, but why the second test done in test/lib/lmb.c test should be considered as
failed ?
ret = lmb_reserve(, 0x4001, 0x1);
ut_asserteq(ret, 0);
ASSERT_LMB(, ram, ram_size, 1, 0x4001, 0x1,
0, 0, 0, 0);
/* allocate overlapping region should fail */
ret = lmb_reserve(, 0x40011000, 0x1);
ut_asserteq(ret, -1);
The 2 area 0x4001 -- 0x1 and 0x40011000 -- 0x1 area overlaps each
other and
should be merged in one 0x4001 -- 11000 ?
What is the criteria to merge or not 2 overlapping areas ?
For me overlapping shouldn't be authorized.
Patrice
>
>> Udit, your patch edb5824be17f ("lmb: remove overlapping region with next
>> range")
>> is authorizing LMB overlapping right ?
>
> As said before this is checking overlap and coalescing and acting accordingly.
>
>> Patrice
>>
>>
>>
>>
>>
Re: [PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
On 4/12/24 17:53, Patrice Chotard wrote:
> In case a new region is adjacent to a previous region with
> similar flag, this region is merged with its predecessor, but no
> check are done if this new added region is overlapping another region
> present in lmb (see reserved[3] which overlaps reserved[4]).
>
> This occurs when the LMB [0xdaafd000-0xddb18000] is added and overlaps
> the LMB [0xdbaf4380-0xddff].
>
> Call lmb_overlaps_region() before merging the new region with the
> adjacent region already present in lmb.
>
> In case of adjacent region found, code is 90% similar in case
> adjacent region is located before/after the new region.
> Factorize adjacent region management in lmb_add_region_flags().
>
> Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
> shows:
>
> before this patch:
> ...
> lmb_dump_all:
> memory.cnt = 0x1 / max = 0x2
> memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
> reserved.cnt = 0x5 / 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][0xdaae1000-0xdfff], 0x0551f000 bytes flags: 0
> reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
> ...
>
> after this patch:
>
> ...
> lmb_dump_all:
> memory.cnt = 0x1 / max = 0x2
> memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
> reserved.cnt = 0x5 / 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][0xdaae1000-0xddff], 0x0351f000 bytes flags: 0
> reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
> ...
>
> Fixes: 4ed6552f7159 ("[new uImage] Introduce lmb from linux kernel for memory
> mgmt of boot images")
>
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v2:
> _ Fix lmb_add_region_flags() by updating test which leads to
> extend an existing region
>
> lib/lmb.c | 57 +--
> 1 file changed, 30 insertions(+), 27 deletions(-)
>
> diff --git a/lib/lmb.c b/lib/lmb.c
> index b6afb731440..4ed60f4a843 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -130,6 +130,22 @@ static void lmb_fix_over_lap_regions(struct lmb_region
> *rgn, unsigned long r1,
> lmb_remove_region(rgn, r2);
> }
>
> +static long lmb_overlaps_region(struct lmb_region *rgn, phys_addr_t base,
> + phys_size_t size)
> +{
> + unsigned long i;
> +
> + for (i = 0; i < rgn->cnt; i++) {
> + phys_addr_t rgnbase = rgn->region[i].base;
> + phys_size_t rgnsize = rgn->region[i].size;
> +
> + if (lmb_addrs_overlap(base, size, rgnbase, rgnsize))
> + break;
> + }
> +
> + return (i < rgn->cnt) ? i : -1;
> +}
> +
> void lmb_init(struct lmb *lmb)
> {
> #if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
> @@ -257,7 +273,7 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
> phys_addr_t base,
>phys_size_t size, enum lmb_flags flags)
> {
> unsigned long coalesced = 0;
> - long adjacent, i;
> + long adjacent, i, overlap;
>
> if (rgn->cnt == 0) {
> rgn->region[0].base = base;
> @@ -283,19 +299,21 @@ static long lmb_add_region_flags(struct lmb_region
> *rgn, phys_addr_t base,
> }
>
> adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
> - if (adjacent > 0) {
> - if (flags != rgnflags)
> - continue;
> - rgn->region[i].base -= size;
> - rgn->region[i].size += size;
> - coalesced++;
> - break;
> - } else if (adjacent < 0) {
> + if (adjacent != 0) {
> if (flags != rgnflags)
> continue;
> - rgn->region[i].size += size;
> - coalesced++;
> - break;
> + overlap = lmb_overlaps_region(rgn, base, size);
> + if (overlap < 0 || flags == rgn->region[overlap].flags)
> {
> + /*
> + * no overlap detected or overlap with same
> flags detected,
> +
[PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
In case a new region is adjacent to a previous region with
similar flag, this region is merged with its predecessor, but no
check are done if this new added region is overlapping another region
present in lmb (see reserved[3] which overlaps reserved[4]).
This occurs when the LMB [0xdaafd000-0xddb18000] is added and overlaps
the LMB [0xdbaf4380-0xddff].
Call lmb_overlaps_region() before merging the new region with the
adjacent region already present in lmb.
In case of adjacent region found, code is 90% similar in case
adjacent region is located before/after the new region.
Factorize adjacent region management in lmb_add_region_flags().
Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
shows:
before this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / 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][0xdaae1000-0xdfff], 0x0551f000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
after this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / 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][0xdaae1000-0xddff], 0x0351f000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
Fixes: 4ed6552f7159 ("[new uImage] Introduce lmb from linux kernel for memory
mgmt of boot images")
Signed-off-by: Patrice Chotard
---
Changes in v2:
_ Fix lmb_add_region_flags() by updating test which leads to
extend an existing region
lib/lmb.c | 57 +--
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index b6afb731440..4ed60f4a843 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -130,6 +130,22 @@ static void lmb_fix_over_lap_regions(struct lmb_region
*rgn, unsigned long r1,
lmb_remove_region(rgn, r2);
}
+static long lmb_overlaps_region(struct lmb_region *rgn, phys_addr_t base,
+ phys_size_t size)
+{
+ unsigned long i;
+
+ for (i = 0; i < rgn->cnt; i++) {
+ phys_addr_t rgnbase = rgn->region[i].base;
+ phys_size_t rgnsize = rgn->region[i].size;
+
+ if (lmb_addrs_overlap(base, size, rgnbase, rgnsize))
+ break;
+ }
+
+ return (i < rgn->cnt) ? i : -1;
+}
+
void lmb_init(struct lmb *lmb)
{
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
@@ -257,7 +273,7 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
phys_size_t size, enum lmb_flags flags)
{
unsigned long coalesced = 0;
- long adjacent, i;
+ long adjacent, i, overlap;
if (rgn->cnt == 0) {
rgn->region[0].base = base;
@@ -283,19 +299,21 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
}
adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
- if (adjacent > 0) {
- if (flags != rgnflags)
- continue;
- rgn->region[i].base -= size;
- rgn->region[i].size += size;
- coalesced++;
- break;
- } else if (adjacent < 0) {
+ if (adjacent != 0) {
if (flags != rgnflags)
continue;
- rgn->region[i].size += size;
- coalesced++;
- break;
+ overlap = lmb_overlaps_region(rgn, base, size);
+ if (overlap < 0 || flags == rgn->region[overlap].flags)
{
+ /*
+* no overlap detected or overlap with same
flags detected,
+* extend region
+*/
+ if (adjacent > 0)
+ rgn->region[i].base -= size;
+ rgn->region[i].size += size;
+ coalesced++;
+ break;
+ }
} else if (lmb_addrs_overlap(base, size, rgnbase, rgnsize)) {
/* regions overlap */
return -1;
@@ -420,21 +438,6 @@ long lmb_reserve(struct lmb *lmb, phys_addr_t bas
[PATCH v2 1/2] lmb: Avoid to add identical region in lmb_add_region_flags()
In case lmb_add_region_flags() is called with the same parameter than
an already existing lmb and this lmb is adjacent to its previous lmb with
different flag, this lmb is added again.
Instead breaking the loop, continue, at the next iteration, we are able
to detect that this region already exist.
Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
shows:
Before this patch, the last LMB [0xde00-0xdfff] is duplicated:
...
lmb_dump_all:nnn
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][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
reserved[5][0xde00-0xdfff], 0x0200 bytes flags: 4
...
After this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / 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][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
Fixes: 59c0ea5df33f ("lmb: Add support of flags for no-map properties")
Signed-off-by: Patrice Chotard
---
(no changes since v1)
lib/lmb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 44f98205310..b6afb731440 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -285,14 +285,14 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
if (adjacent > 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].base -= size;
rgn->region[i].size += size;
coalesced++;
break;
} else if (adjacent < 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].size += size;
coalesced++;
break;
--
2.25.1
Re: [PATCH 1/2] lmb: Avoid to add identical region in lmb_add_region_flags()
On 4/10/24 17:28, Tom Rini wrote:
> On Mon, Mar 11, 2024 at 03:39:17PM +0100, Patrice Chotard wrote:
>
>> In case lmb_add_region_flags() is called with the same parameter than
>> an already existing lmb and this lmb is adjacent to its previous lmb with
>> different flag, this lmb is added again.
>>
>> Instead breaking the loop, continue, at the next iteration, we are able
>> to detect that this region already exist.
>>
>> Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
>> shows:
>>
>> Before this patch, the last LMB [0xde00-0xdfff] is duplicated:
>> ...
>> lmb_dump_all:nnn
>> 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][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
>> reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
>> reserved[5][0xde00-0xdfff], 0x0200 bytes flags: 4
>> ...
>>
>> After this patch:
>> ...
>> lmb_dump_all:
>> memory.cnt = 0x1 / max = 0x2
>> memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
>> reserved.cnt = 0x5 / 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][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
>> reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
>> ...
>>
>> Fixes: 59c0ea5df33f ("lmb: Add support of flags for no-map properties")
>>
>> Signed-off-by: Patrice Chotard
>
> This series leads to CI failures:
> https://source.denx.de/u-boot/u-boot/-/jobs/814084
>
Hi Tom
i will have a look at it , thanks
Patrice
[PATCH v1 25/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index b38e816f888..7c0d1bab11a 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -12,7 +12,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
};
@@ -36,6 +36,10 @@
led {
compatible = "gpio-leds";
+ led-blue {
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 21/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 09cfe9bc246..d93359f967c 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -14,7 +14,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
};
@@ -61,6 +61,10 @@
led {
compatible = "gpio-leds";
+ led-blue {
+ gpios = < 9 GPIO_ACTIVE_HIGH>;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 20/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index edcbfee0fc7..09cfe9bc246 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -15,7 +15,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
};
@@ -59,10 +59,10 @@
};
led {
- red {
- label = "error";
+ compatible = "gpio-leds";
+
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 22/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ button-user-2 for fastboot mode activation.
Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 4d763bd3a2c..84920f53496 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -3,6 +3,7 @@
* Copyright : STMicroelectronics 2022
*/
+#include
#include "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -14,8 +15,22 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "u-boot-env";
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
};
led {
--
2.25.1
[PATCH v1 24/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 2abd512e297..b38e816f888 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -13,7 +13,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
};
@@ -34,10 +34,10 @@
};
led {
- red {
- label = "error";
+ compatible = "gpio-leds";
+
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
index 84920f53496..2abd512e297 100644
--- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
@@ -37,7 +37,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 18/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ button-user-2 for fastboot mode activation.
Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index ef91088aa37..e6a452c9d8e 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "stm32mp15-u-boot.dtsi"
#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
@@ -16,8 +17,6 @@
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
};
#if defined(CONFIG_STM32MP15X_STM32IMAGE) || defined(CONFIG_SPL)
@@ -43,6 +42,22 @@
};
#endif
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+ };
+
led {
red {
label = "error";
--
2.25.1
[PATCH v1 19/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index e6a452c9d8e..edcbfee0fc7 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -62,7 +62,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 17/25] ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 92153b2a657..f97debaa0e4 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -15,7 +15,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
@@ -64,6 +64,10 @@
};
led {
+ led-blue {
+ /delete-property/label;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 16/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index ee9b51d42b7..92153b2a657 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -16,7 +16,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
};
@@ -64,10 +64,8 @@
};
led {
- red {
- label = "error";
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 15/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 6bf6136c5fd..ee9b51d42b7 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -67,7 +67,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 14/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index a16358266a2..6bf6136c5fd 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "stm32mp15-u-boot.dtsi"
#include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
@@ -18,8 +19,6 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
};
#if defined(CONFIG_STM32MP15X_STM32IMAGE) || defined(CONFIG_SPL)
@@ -48,6 +47,22 @@
};
#endif
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+ };
+
led {
red {
label = "error";
--
2.25.1
[PATCH v1 11/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 5d49b09c35d..8760d6c7d93 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -39,7 +39,6 @@
red {
label = "error";
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
status = "okay";
};
};
--
2.25.1
[PATCH v1 12/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 8760d6c7d93..e61814fd66e 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -14,7 +14,7 @@
config {
u-boot,boot-led = "heartbeat";
- u-boot,error-led = "error";
+ u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
};
@@ -36,10 +36,8 @@
};
led {
- red {
- label = "error";
+ led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
- status = "okay";
};
};
};
--
2.25.1
[PATCH v1 10/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index 20728f27ee1..5d49b09c35d 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -3,6 +3,7 @@
* Copyright : STMicroelectronics 2022
*/
+#include
#include "stm32mp15-scmi-u-boot.dtsi"
/ {
@@ -16,8 +17,22 @@
u-boot,error-led = "error";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
- st,fastboot-gpios = < 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- st,stm32prog-gpios = < 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user-2 {
+ label = "User-2";
+ linux,code = ;
+ gpios = < 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
};
led {
--
2.25.1
[PATCH v1 13/25] ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
index e61814fd66e..a5158fec7ef 100644
--- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
@@ -13,7 +13,7 @@
};
config {
- u-boot,boot-led = "heartbeat";
+ u-boot,boot-led = "led-blue";
u-boot,error-led = "led-red";
u-boot,mmc-env-partition = "u-boot-env";
st,adc_usb_pd = < 18>, < 19>;
@@ -36,6 +36,10 @@
};
led {
+ led-blue {
+ /delete-property/label;
+ };
+
led-red {
gpios = < 13 GPIO_ACTIVE_LOW>;
};
--
2.25.1
[PATCH v1 09/25] ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot
Remove "color" property from led-red node which is not supported
by U-Boot.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index 8f42735609a..f004e9840a2 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -35,7 +35,6 @@
};
led-red {
- color = ;
gpios = < 13 GPIO_ACTIVE_LOW>;
};
};
--
2.25.1
[PATCH v1 05/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp13_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index db09e63100e..caaabf39ef3 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -52,6 +52,8 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=-1 CONFIG_ENV_MMC_USE_DT=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 06/25] board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()
Instead of using gpio directly to detect key pressed on button
dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS.
Signed-off-by: Patrice Chotard
---
board/st/stm32mp1/stm32mp1.c | 68 +---
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index a17c314daeb..82f7d4ff4ea 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -38,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -150,45 +152,55 @@ int checkboard(void)
static void board_key_check(void)
{
- ofnode node;
- struct gpio_desc gpio;
+ struct udevice *button1 = NULL, *button2 = NULL;
enum forced_boot_mode boot_mode = BOOT_NORMAL;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_BUTTON))
+ return;
if (!IS_ENABLED(CONFIG_FASTBOOT) && !IS_ENABLED(CONFIG_CMD_STM32PROG))
return;
- node = ofnode_path("/config");
- if (!ofnode_valid(node)) {
- log_debug("no /config node?\n");
+ if (IS_ENABLED(CONFIG_CMD_STM32PROG))
+ button_get_by_label("User-1", );
+
+ if (IS_ENABLED(CONFIG_FASTBOOT))
+ button_get_by_label("User-2", );
+
+ if (!button1 && !button2)
return;
- }
- if (IS_ENABLED(CONFIG_FASTBOOT)) {
- if (gpio_request_by_name_nodev(node, "st,fastboot-gpios", 0,
- , GPIOD_IS_IN)) {
- log_debug("could not find a
/config/st,fastboot-gpios\n");
- } else {
- udelay(20);
- if (dm_gpio_get_value()) {
- log_notice("Fastboot key pressed, ");
- boot_mode = BOOT_FASTBOOT;
- }
- dm_gpio_free(NULL, );
+ if (button2) {
+ if (button_get_state(button2) == BUTTON_ON) {
+ log_notice("Fastboot key pressed, ");
+ boot_mode = BOOT_FASTBOOT;
}
+ /*
+* On some boards, same gpio is shared betwwen gpio-keys and
+* leds, remove the button device to free the gpio for led
+* usage
+*/
+ ret = device_remove(button2, DM_REMOVE_NORMAL);
+ if (ret)
+ log_err("Can't remove button2 (%d)\n", ret);
}
- if (IS_ENABLED(CONFIG_CMD_STM32PROG)) {
- if (gpio_request_by_name_nodev(node, "st,stm32prog-gpios", 0,
- , GPIOD_IS_IN)) {
- log_debug("could not find a
/config/st,stm32prog-gpios\n");
- } else {
- udelay(20);
- if (dm_gpio_get_value()) {
- log_notice("STM32Programmer key pressed, ");
- boot_mode = BOOT_STM32PROG;
- }
- dm_gpio_free(NULL, );
+
+ if (button1) {
+ if (button_get_state(button1) == BUTTON_ON) {
+ log_notice("STM32Programmer key pressed, ");
+ boot_mode = BOOT_STM32PROG;
}
+ /*
+* On some boards, same gpio is shared betwwen gpio-keys and
+* leds, remove the button device to free the gpio for led
+* usage
+*/
+ ret = device_remove(button1, DM_REMOVE_NORMAL);
+ if (ret)
+ log_err("Can't remove button1 (%d)\n", ret);
}
+
if (boot_mode != BOOT_NORMAL) {
log_notice("entering download mode...\n");
clrsetbits_le32(TAMP_BOOT_CONTEXT,
--
2.25.1
[PATCH v1 07/25] ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ update button-user's label (defined in kernel DT) to match label
requested in board_key_check() for fastboot mode activation.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index ba0c02489d1..e64ded13462 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -16,6 +16,19 @@
u-boot,mmc-env-partition = "u-boot-env";
};
+ gpio-keys {
+ button-user-1 {
+ label = "User-1";
+ linux,code = ;
+ gpios = < 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ };
+
+ button-user {
+ /* update label to match the label requested in
board_key_check() */
+ label = "User-2";
+ };
+ };
+
leds {
led-red {
color = ;
--
2.25.1
[PATCH v1 08/25] ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from led-red and
led-blue led's node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard
---
arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
index e64ded13462..8f42735609a 100644
--- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
@@ -30,10 +30,13 @@
};
leds {
+ led-blue {
+ /delete-property/default-state;
+ };
+
led-red {
color = ;
gpios = < 13 GPIO_ACTIVE_LOW>;
- default-state = "off";
};
};
};
--
2.25.1
[PATCH v1 03/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_basic_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 005f1d55f80..2e22bf86000 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -97,6 +97,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0xC000 -- 2.25.1
[PATCH v1 04/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_trusted_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 84b0854b557..74deaaba2e4 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -70,6 +70,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 02/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard --- configs/stm32mp15_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig index 3302b306996..ffe7512650e 100644 --- a/configs/stm32mp15_defconfig +++ b/configs/stm32mp15_defconfig @@ -69,6 +69,8 @@ CONFIG_TFTP_TSIZE=y CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.1.1" CONFIG_STM32_ADC=y +CONFIG_BUTTON=y +CONFIG_BUTTON_GPIO=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y CONFIG_USB_FUNCTION_FASTBOOT=y -- 2.25.1
[PATCH v1 00/25] stm32mp: Fix keys & leds management
Adding FASTBOOT support for stm32mp13 shows issues when entering in fastboot mode using a dedicated key. On several STM32MP boards, same gpio is shared between key and led. Restore the fastboot/stm32prog activation using a dedicated key. Restore the led-blue which indicates U-Boot entering / exit. Make usage of BUTTON-UCLASS for key management on STM32MP1. Patrice Chotard (25): configs: stm32mp13: Enable FASTBOOT configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check() ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update u-boot,boot-led for stm32mp157a-dk1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 19 +- arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 34 +++--- arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 34 +++--- board/st/stm32mp1/stm32mp1.c | 68 +++ configs/stm32mp13_defconfig | 11 ++- configs/stm32mp15_basic_defconfig | 2 + configs/stm32mp15_defconfig | 2 + configs/stm32mp15_trusted_defconfig | 2 + 10 files changed, 173 insertions(+), 63 deletions(-) -- 2.25.1
[PATCH v1 01/25] configs: stm32mp13: Enable FASTBOOT
Enable FASTBOOT relative flags for stm32mp13_defconfig. Signed-off-by: Patrice Chotard --- configs/stm32mp13_defconfig | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index c893e272db9..db09e63100e 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -15,6 +15,7 @@ CONFIG_CMD_STM32PROG=y CONFIG_SYS_LOAD_ADDR=0xc200 CONFIG_SYS_MEMTEST_START=0xc000 CONFIG_SYS_MEMTEST_END=0xc400 +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_DISTRO_DEFAULTS=y @@ -53,6 +54,13 @@ CONFIG_SYS_MMC_ENV_DEV=-1 CONFIG_ENV_MMC_USE_DT=y CONFIG_CLK_SCMI=y CONFIG_SET_DFU_ALT_INFO=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0xc000 +CONFIG_FASTBOOT_BUF_SIZE=0x0200 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y CONFIG_GPIO_HOG=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_STM32F7=y @@ -92,7 +100,6 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y -CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_ERRNO_STR=y # CONFIG_LMB_USE_MAX_REGIONS is not set CONFIG_LMB_MEMORY_REGIONS=2 -- 2.25.1
Re: [PATCH v2] ARM: stm32: Jump to ep on successful resume in PSCI suspend code
On 4/7/24 22:21, Marek Vasut wrote:
> In case the system has resumed successfully, the PSCI suspend resume
> code has to jump to the 'ep' successful resume entry point code path,
> otherwise the code has to jump to content of the LR register, which
> points to failed resume code path.
>
> To implement this distinction, rewrite LR register stored on stack
> with 'ep' value in case of a successful resume, which is really in
> every case unless some catastrophic failure occurred during suspend.
>
> Without this change, Linux counts every resume as failed in
> /sys/power/suspend_stats/fail
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Rebase on u-boot/master
> ---
> arch/arm/mach-stm32mp/stm32mp1/psci.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> index 8cdeb0ab3f2..4f2379df45f 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> @@ -703,6 +703,8 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
> {
> u32 saved_mcudivr, saved_pll3cr, saved_pll4cr, saved_mssckselr;
> u32 gicd_addr = stm32mp_get_gicd_base_address();
> + u32 cpu = psci_get_cpu_id();
> + u32 sp = (u32)__secure_stack_end - (cpu << ARM_PSCI_STACK_SHIFT);
> bool iwdg1_wake = false;
> bool iwdg2_wake = false;
> bool other_wake = false;
> @@ -805,4 +807,16 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
>
> writel(SYSCFG_CMPENR_MPUEN, STM32_SYSCFG_BASE + SYSCFG_CMPENSETR);
> clrbits_le32(STM32_SYSCFG_BASE + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
> +
> + /*
> + * The system has resumed successfully. Rewrite LR register stored
> + * on stack with 'ep' value, so that on return from this PSCI call,
> + * the code would jump to that 'ep' resume entry point code path
> + * instead of the previous 'lr' register content which (e.g. with
> + * Linux) points to resume failure code path.
> + *
> + * See arch/arm/cpu/armv7/psci.S _smc_psci: for the stack layout
> + * used here, SP-4 is PC, SP-8 is LR, SP-12 is R7, and so on.
> + */
> + writel(ep, sp - 8);
> }
Reviewed-by: Patrice Chotard
Thanks
Patrice
[PATCH] net: dwc_eth_qos: Fix compilation warning in eqos_free_pkt()
Fix compilation warning:
../arch/arm/include/asm/io.h: In function 'eqos_free_pkt':
../arch/arm/include/asm/io.h:103:32: warning: 'rx_desc' may be used
uninitialized [-Wmaybe-uninitialized]
103 | #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c);
__v; })
|^~~
../drivers/net/dwc_eth_qos.c:1220:27: note: 'rx_desc' was declared here
1220 | struct eqos_desc *rx_desc;
| ^~~
Signed-off-by: Patrice Chotard
---
drivers/net/dwc_eth_qos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 9b3bce1dc87..9df3dde14f1 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1217,7 +1217,7 @@ static int eqos_free_pkt(struct udevice *dev, uchar
*packet, int length)
struct eqos_priv *eqos = dev_get_priv(dev);
u32 idx, idx_mask = eqos->desc_per_cacheline - 1;
uchar *packet_expected;
- struct eqos_desc *rx_desc;
+ struct eqos_desc *rx_desc = NULL;
debug("%s(packet=%p, length=%d)\n", __func__, packet, length);
--
2.25.1
Re: [PATCH] ARM: stm32: Jump to ep on successful resume in PSCI suspend code
On 3/31/24 20:21, Marek Vasut wrote:
> In case the system has resumed successfully, the PSCI suspend resume
> code has to jump to the 'ep' successful resume entry point code path,
> otherwise the code has to jump to content of the LR register, which
> points to failed resume code path.
>
> To implement this distinction, rewrite LR register stored on stack
> with 'ep' value in case of a successful resume, which is really in
> every case unless some catastrophic failure occurred during suspend.
>
> Without this change, Linux counts every resume as failed in
> /sys/power/suspend_stats/fail
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/psci.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c
> index 8cdeb0ab3f2..4f2379df45f 100644
> --- a/arch/arm/mach-stm32mp/psci.c
> +++ b/arch/arm/mach-stm32mp/psci.c
> @@ -703,6 +703,8 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
> {
> u32 saved_mcudivr, saved_pll3cr, saved_pll4cr, saved_mssckselr;
> u32 gicd_addr = stm32mp_get_gicd_base_address();
> + u32 cpu = psci_get_cpu_id();
> + u32 sp = (u32)__secure_stack_end - (cpu << ARM_PSCI_STACK_SHIFT);
> bool iwdg1_wake = false;
> bool iwdg2_wake = false;
> bool other_wake = false;
> @@ -805,4 +807,16 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
>
> writel(SYSCFG_CMPENR_MPUEN, STM32_SYSCFG_BASE + SYSCFG_CMPENSETR);
> clrbits_le32(STM32_SYSCFG_BASE + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
> +
> + /*
> + * The system has resumed successfully. Rewrite LR register stored
> + * on stack with 'ep' value, so that on return from this PSCI call,
> + * the code would jump to that 'ep' resume entry point code path
> + * instead of the previous 'lr' register content which (e.g. with
> + * Linux) points to resume failure code path.
> + *
> + * See arch/arm/cpu/armv7/psci.S _smc_psci: for the stack layout
> + * used here, SP-4 is PC, SP-8 is LR, SP-12 is R7, and so on.
> + */
> + writel(ep, sp - 8);
> }
Hi Marek
This patch is not based on last next or master branch, psci.c is now located in
arch/arm/mach-stm32mp/stm32mp1/psci.c
Nevertheless, you can add my RB on the V2.
Thanks
Patrice
Re: [PATCH] ARM: imx: stm32: Test whether ethernet node is enabled before reading MAC EEPROM on DHSOM
On 3/12/24 22:15, Marek Vasut wrote:
> Check whether the ethernet interface is enabled at all before reading
> MAC EEPROM. As a cost saving measure, it can happen that the MAC EEPROM
> is not populated on SoMs which do not use ethernet.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "NXP i.MX U-Boot Team"
> Cc: Andreas Geisreiter
> Cc: Christoph Niedermaier
> Cc: Fabio Estevam
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Stefano Babic
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> NOTE: It is probably best if this goes in via either imx or stm32 tree,
> I can break the patch up, but that would introduce dependency
> between two PRs in different trees. Let me know what you prefer.
> ---
> board/dhelectronics/common/dh_common.c | 16
> board/dhelectronics/common/dh_common.h | 8
> board/dhelectronics/dh_imx6/dh_imx6.c| 3 +++
> .../dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c | 6 ++
> board/dhelectronics/dh_stm32mp1/board.c | 6 ++
> 5 files changed, 39 insertions(+)
>
> diff --git a/board/dhelectronics/common/dh_common.c
> b/board/dhelectronics/common/dh_common.c
> index 67e3d59b1f3..34094a020b0 100644
> --- a/board/dhelectronics/common/dh_common.c
> +++ b/board/dhelectronics/common/dh_common.c
> @@ -18,6 +18,19 @@ bool dh_mac_is_in_env(const char *env)
> return eth_env_get_enetaddr(env, enetaddr);
> }
>
> +int dh_get_mac_is_enabled(const char *alias)
> +{
> + ofnode node = ofnode_path(alias);
> +
> + if (!ofnode_valid(node))
> + return -EINVAL;
> +
> + if (!ofnode_is_enabled(node))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> int dh_get_mac_from_eeprom(unsigned char *enetaddr, const char *alias)
> {
> struct udevice *dev;
> @@ -57,6 +70,9 @@ __weak int dh_setup_mac_address(void)
> if (dh_mac_is_in_env("ethaddr"))
> return 0;
>
> + if (dh_get_mac_is_enabled("ethernet0"))
> + return 0;
> +
> if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
> return eth_env_set_enetaddr("ethaddr", enetaddr);
>
> diff --git a/board/dhelectronics/common/dh_common.h
> b/board/dhelectronics/common/dh_common.h
> index 2b24637d96d..a2de5b1553e 100644
> --- a/board/dhelectronics/common/dh_common.h
> +++ b/board/dhelectronics/common/dh_common.h
> @@ -11,6 +11,14 @@
> */
> bool dh_mac_is_in_env(const char *env);
>
> +/*
> + * dh_get_mac_is_enabled - Test if ethernet MAC is enabled in DT
> + *
> + * @alias: alias for ethernet MAC device tree node
> + * Return: 0 if OK, other value on error
> + */
> +int dh_get_mac_is_enabled(const char *alias);
> +
> /*
> * dh_get_mac_from_eeprom - Get MAC address from eeprom and write it to
> enetaddr
> *
> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
> b/board/dhelectronics/dh_imx6/dh_imx6.c
> index 07fc9b1fe6d..0676587c38a 100644
> --- a/board/dhelectronics/dh_imx6/dh_imx6.c
> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
> @@ -92,6 +92,9 @@ int dh_setup_mac_address(void)
> if (dh_mac_is_in_env("ethaddr"))
> return 0;
>
> + if (dh_get_mac_is_enabled("ethernet0"))
> + return 0;
> +
> if (!dh_imx_get_mac_from_fuse(enetaddr))
> goto out;
>
> diff --git a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> index 5f12d787d38..ff2c0e87215 100644
> --- a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> @@ -47,6 +47,9 @@ static int dh_imx8_setup_ethaddr(void)
> if (dh_mac_is_in_env("ethaddr"))
> return 0;
>
> + if (dh_get_mac_is_enabled("ethernet0"))
> + return 0;
> +
> if (!dh_imx_get_mac_from_fuse(enetaddr))
> goto out;
>
> @@ -66,6 +69,9 @@ static int dh_imx8_setup_eth1addr(void)
> if (dh_mac_is_in_env("eth1addr"))
> return 0;
>
> + if (dh_get_mac_is_enabled("ethernet1"))
> + return 0;
> +
> if (!dh_imx_get_mac_from_fuse(enetaddr))
> goto increment_out;
>
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c
> b/board/dhelectronics/dh_stm32mp1/board.c
> index 88eb7d1b8d4..b3309c9d330 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -129,6 +129,9
Re: [PATCH] ARM: imx: stm32: Test whether ethernet node is enabled before reading MAC EEPROM on DHSOM
On 3/13/24 01:52, Fabio Estevam wrote: > Hi Marek, > > On Tue, Mar 12, 2024 at 6:16 PM Marek Vasut wrote: > >> NOTE: It is probably best if this goes in via either imx or stm32 tree, >> I can break the patch up, but that would introduce dependency >> between two PRs in different trees. Let me know what you prefer. > Hi Marek, Fabio Sorry for the delay. > I can apply it to u-boot-imx next if Patrice and Patrick are OK. yes, you can apply it directly through u-boot-imx next. Thanks Patrice
Re: [PATCH] ARM: stm32: Default dfu_alt_info for STM32MP13xx SPI NOR
On 3/26/24 18:08, Marek Vasut wrote: > On 3/19/24 11:22 AM, Patrice CHOTARD wrote: >> >> >> On 3/19/24 03:44, Marek Vasut wrote: >>> Define dfu_alt_info with SPI NOR layout to make it easy to >>> install or update bootloader in the SPI NOR using dfu-util. >>> >>> Use the following U-Boot commands to start DFU mode: >>> " >>> => sf probe && dfu 0 mtd >>> " >>> >>> Use the following dfu-util invocation on Host PC to install binaries: >>> " >>> $ dfu-util -w -a 0 -D >>> build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32 >>> $ dfu-util -w -a 1 -D >>> build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32 >>> $ dfu-util -w -a 2 -D build/stm32mp1/release/fip.bin >>> " >>> >>> Signed-off-by: Marek Vasut >>> --- >>> Cc: Patrice Chotard >>> Cc: Patrick Delaunay >>> Cc: Tom Rini >>> Cc: u-b...@dh-electronics.com >>> Cc: u-boot@lists.denx.de >>> Cc: uboot-st...@st-md-mailman.stormreply.com >>> --- >>> include/configs/stm32mp13_common.h | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/include/configs/stm32mp13_common.h >>> b/include/configs/stm32mp13_common.h >>> index 5b0658ced92..d6e4f8fd915 100644 >>> --- a/include/configs/stm32mp13_common.h >>> +++ b/include/configs/stm32mp13_common.h >>> @@ -63,6 +63,7 @@ >>> "fi;\0" >>> #define STM32MP_EXTRA \ >>> + "dfu_alt_info=mtd nor0=fsbl1 raw 0x0 0x4;fsbl2 raw 0x4 >>> 0x4;uboot raw 0x8 0x16\0" \ >>> "env_check=if env info -p -d -q; then env save; fi\0" \ >>> "boot_net_usb_start=true\0" >>> >> >> >> Hi Marek >> >> On our STM32 board, the dfu_alt_info is build dynamically, we have >> CONFIG_SET_DFU_ALT_INFO enable >> Can you add the dfu_alt_info in a specific stm32mp13_dhxx.common.h instead ? > > You can drop this patch. Ok thanks Patrice
Re: [PATCH 1/1] fs: ext4: all file paths are absolute
On 3/20/24 14:25, Heinrich Schuchardt wrote:
> U-Boot only knows absolute file paths. It is inconsistent to require that
> saving to an ext4 file system should use a leading '/' wile reading does
> not. Remove the superfluous check.
>
> Reported-by: Patrice Chotard
> Signed-off-by: Heinrich Schuchardt
> ---
> fs/ext4/ext4_common.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index ea9b92298ba..9eac6beef3b 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -765,11 +765,6 @@ int ext4fs_get_parent_inode_num(const char *dirname,
> char *dname, int flags)
> struct ext2_inode *first_inode = NULL;
> struct ext2_inode temp_inode;
>
> - if (*dirname != '/') {
> - printf("Please supply Absolute path\n");
> - return -1;
> - }
> -
> /* TODO: input validation make equivalent to linux */
> depth_dirname = zalloc(strlen(dirname) + 1);
> if (!depth_dirname)
Tested-by: Patrice Chotard
Thanks
Patrice
