[PATCH v4] Altera SoCFpga Boot Stall Fix

[PATCH v4] Altera SoCFpga Boot Stall Fix

[Brian Sune]

Since U-Boot 2025.07 pure SD Card
boot no longer works. Now Altera released 2025.07
shows the different on the u-boot files.
After testing, the major root case is
get_managers_addr. And this patch fix the
SD boot stall via pulling from offical.

Signed-off-by: Brian Sune <briansune@gmail.com>
---
 arch/arm/mach-socfpga/misc.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 76747c2196a..c54f5e32454 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -178,7 +178,10 @@ int arch_cpu_init(void)
 	 * timeout value is still active which might too short for Linux
 	 * booting.
 	 */
+#if !(IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS) || \
+	IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU))
 	hw_watchdog_init();
+#endif
 #else
 	/*
 	 * If the HW watchdog is NOT enabled, make sure it is not running,
@@ -223,8 +226,16 @@ static int do_bridge(struct cmd_tbl *cmdtp, int flag, int argc,
 
 U_BOOT_CMD(bridge, 3, 1, do_bridge,
 	   "SoCFPGA HPS FPGA bridge control",
-	   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
-	   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
+	   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
+	   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
+	   "Bit 3, Bit 4 and Bit 5 bridges only available in Stratix 10\n"
+	   "For example:\n"
+	   "1) To enable and disable all bridges (command without mask):\n"
+	   "	a) bridge enable\n"
+	   "	b) bridge disable\n"
+	   "2) To enable and disable HPS-to-FPGA and LWHPS-to-FPGA bridges (command with mask):\n"
+	   "	a) bridge enable 0x3\n"
+	   "	b) bridge disable 0x3\n"
 	   ""
 );
 
@@ -261,6 +272,17 @@ void socfpga_get_managers_addr(void)
 	if (ret)
 		hang();
 
+	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {
+		ret = socfpga_get_base_addr("altr,sys-mgr",
+					    &socfpga_sysmgr_base);
+		if (ret)
+			hang();
+	}
+
+	if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) ||
+	    IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M))
+		ret = socfpga_get_base_addr("intel,agilex-clkmgr",
+					    &socfpga_clkmgr_base);
 	else if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))
 		ret = socfpga_get_base_addr("intel,n5x-clkmgr",
 					    &socfpga_clkmgr_base);
-- 
2.25.1

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Chee, Tien Fong]

Hi,

On 20/10/2025 9:34 pm, Brian Sune wrote:
> Since U-Boot 2025.07 pure SD Card
> boot no longer works. Now Altera released 2025.07
> shows the different on the u-boot files.
> After testing, the major root case is
> get_managers_addr. And this patch fix the
> SD boot stall via pulling from offical.
>
> Signed-off-by: Brian Sune<briansune@gmail.com>
> ---
>   arch/arm/mach-socfpga/misc.c | 26 ++++++++++++++++++++++++--
>   1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index 76747c2196a..c54f5e32454 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -178,7 +178,10 @@ int arch_cpu_init(void)
>   	 * timeout value is still active which might too short for Linux
>   	 * booting.
>   	 */
> +#if !(IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS) || \
> +	IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU))
>   	hw_watchdog_init();
> +#endif


This is intended for internal use and should be removed.


>   #else
>   	/*
>   	 * If the HW watchdog is NOT enabled, make sure it is not running,
> @@ -223,8 +226,16 @@ static int do_bridge(struct cmd_tbl *cmdtp, int flag, int argc,
>   
>   U_BOOT_CMD(bridge, 3, 1, do_bridge,
>   	   "SoCFPGA HPS FPGA bridge control",
> -	   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> -	   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> +	   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +	   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +	   "Bit 3, Bit 4 and Bit 5 bridges only available in Stratix 10\n"
> +	   "For example:\n"
> +	   "1) To enable and disable all bridges (command without mask):\n"
> +	   "	a) bridge enable\n"
> +	   "	b) bridge disable\n"
> +	   "2) To enable and disable HPS-to-FPGA and LWHPS-to-FPGA bridges (command with mask):\n"
> +	   "	a) bridge enable 0x3\n"
> +	   "	b) bridge disable 0x3\n"
>   	   ""
>   );
>   
> @@ -261,6 +272,17 @@ void socfpga_get_managers_addr(void)
>   	if (ret)
>   		hang();
>   
> +	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {

if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
         !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M) &&
         !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {


The condition for non-Agilex5 platforms should be rewritten because 
|sys-mgr| has already moved to the driver model for these platforms.


> +		ret = socfpga_get_base_addr("altr,sys-mgr",
> +					    &socfpga_sysmgr_base);
> +		if (ret)
> +			hang();
> +	}
> +
> +	if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) ||
> +	    IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M))
> +		ret = socfpga_get_base_addr("intel,agilex-clkmgr",
> +					    &socfpga_clkmgr_base);


Similarly, the section for Agilex and Agilex7M using |clkmgr| can be 
removed, as both now use the driver model.


>   	else if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))


The N5X section should be updated as:  "if 
(IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))"

The remaining part of the function can remain intact.


>   		ret = socfpga_get_base_addr("intel,n5x-clkmgr",
>   					    &socfpga_clkmgr_base);


We’ve already tested the above changes and they work as expected.


Thanks.

Tien Fong

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Sune Brian]

All the below comment are all just talking about new SoCFPGA.
You break the SD boot by for Cyclone V and Arria V and possible
Arria 10 as well.
You can do a build and board test on SD boot.
Just consider newer SoCFPGA is not a proper way to remove things.

If I am mistaken point out why and what is the reason.
There are nothing to do with new family, this patch is pointing
out the old SoCFPGA is break by such.

Brian

> Hi,
>
> On 20/10/2025 9:34 pm, Brian Sune wrote:
>
> Since U-Boot 2025.07 pure SD Card
> boot no longer works. Now Altera released 2025.07
> shows the different on the u-boot files.
> After testing, the major root case is
> get_managers_addr. And this patch fix the
> SD boot stall via pulling from offical.
>
> Signed-off-by: Brian Sune <briansune@gmail.com>
> ---
>  arch/arm/mach-socfpga/misc.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index 76747c2196a..c54f5e32454 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -178,7 +178,10 @@ int arch_cpu_init(void)
>   * timeout value is still active which might too short for Linux
>   * booting.
>   */
> +#if !(IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS) || \
> + IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU))
>   hw_watchdog_init();
> +#endif
>
>
> This is intended for internal use and should be removed.
>
>
>  #else
>   /*
>   * If the HW watchdog is NOT enabled, make sure it is not running,
> @@ -223,8 +226,16 @@ static int do_bridge(struct cmd_tbl *cmdtp, int flag, int argc,
>
>  U_BOOT_CMD(bridge, 3, 1, do_bridge,
>     "SoCFPGA HPS FPGA bridge control",
> -   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> -   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> +   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +   "Bit 3, Bit 4 and Bit 5 bridges only available in Stratix 10\n"
> +   "For example:\n"
> +   "1) To enable and disable all bridges (command without mask):\n"
> +   " a) bridge enable\n"
> +   " b) bridge disable\n"
> +   "2) To enable and disable HPS-to-FPGA and LWHPS-to-FPGA bridges (command with mask):\n"
> +   " a) bridge enable 0x3\n"
> +   " b) bridge disable 0x3\n"
>     ""
>  );
>
> @@ -261,6 +272,17 @@ void socfpga_get_managers_addr(void)
>   if (ret)
>   hang();
>
> + if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {
>
>
> if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
>         !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M) &&
>         !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {
>
>
> The condition for non-Agilex5 platforms should be rewritten because sys-mgr has already moved to the driver model for these platforms.
>
>
> + ret = socfpga_get_base_addr("altr,sys-mgr",
> +    &socfpga_sysmgr_base);
> + if (ret)
> + hang();
> + }
> +
> + if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) ||
> +    IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M))
> + ret = socfpga_get_base_addr("intel,agilex-clkmgr",
> +    &socfpga_clkmgr_base);
>
>
> Similarly, the section for Agilex and Agilex7M using clkmgr can be removed, as both now use the driver model.
>
>
>   else if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))
>
>
> The N5X section should be updated as:  "if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))"
>
> The remaining part of the function can remain intact.
>
>
>   ret = socfpga_get_base_addr("intel,n5x-clkmgr",
>      &socfpga_clkmgr_base);
>
>
> We’ve already tested the above changes and they work as expected.
>
>
> Thanks.
>
> Tien Fong

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Sune Brian]

>  U_BOOT_CMD(bridge, 3, 1, do_bridge,
>     "SoCFPGA HPS FPGA bridge control",
> -   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> -   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
> +   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
> +   "Bit 3, Bit 4 and Bit 5 bridges only available in Stratix 10\n"
> +   "For example:\n"
> +   "1) To enable and disable all bridges (command without mask):\n"
> +   " a) bridge enable\n"
> +   " b) bridge disable\n"
> +   "2) To enable and disable HPS-to-FPGA and LWHPS-to-FPGA bridges (command with mask):\n"
> +   " a) bridge enable 0x3\n"
> +   " b) bridge disable 0x3\n"
>     ""
>  );

With all do respect. If you have no clue what this is intended.
Read back old 2013- 2019 UBOOT style. These command
and operation is what backward bridge control via boot.scr
or boot env variable.

I am not here to argue, but the patch that touching this file
breaks all Cyclone V SoCFPGA and possible Arria V / 10
SD boot.

Meanwhile, if bridge control method is removed then all
H2F F2H control will be dead. So unless there are very
strong reason or better control method that can support
both old and new bridge control method otherwise no reason
to do so.

Brian

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Chee, Tien Fong]

On 14/11/2025 7:23 pm, Sune Brian wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>

Hi Brian,


> All the below comment are all just talking about new SoCFPGA.
> You break the SD boot by for Cyclone V and Arria V and possible
> Arria 10 as well.
> You can do a build and board test on SD boot.
> Just consider newer SoCFPGA is not a proper way to remove things.
>
> If I am mistaken point out why and what is the reason.
> There are nothing to do with new family, this patch is pointing
> out the old SoCFPGA is break by such.
>

Thanks for your detailed review and feedback.

You are correct, the patch as-is focuses on newer SoCFPGA platforms such 
as Agilex, and Agilex7M, and it does affect SD boot on older platforms 
like Cyclone V, and Arria 10. Our initial assumption was that users 
would primarily use the Altera official release repo, where we have been 
gradually migrating platform devices to the driver model stage by stage, 
including clk driver used in MMC driver.

To clarify, as of today, the driver model has already been implemented 
for Agilex, Agilex7M, and Agilex5. For older SoCFPGA platforms, we will 
ensure that SD boot and existing functionality continue to work while 
maintaining compatibility during this staged migration.

We appreciate your testing and observations. We will take care to 
preserve backward compatibility and address the issues you raised before 
finalizing these changes in mainline.

Thanks,
Tien Fong


>
>> Hi,
>>
>> On 20/10/2025 9:34 pm, Brian Sune wrote:
>>
>> Since U-Boot 2025.07 pure SD Card
>> boot no longer works. Now Altera released 2025.07
>> shows the different on the u-boot files.
>> After testing, the major root case is
>> get_managers_addr. And this patch fix the
>> SD boot stall via pulling from offical.
>>
>> Signed-off-by: Brian Sune <briansune@gmail.com>
>> ---
>>   arch/arm/mach-socfpga/misc.c | 26 ++++++++++++++++++++++++--
>>   1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>> index 76747c2196a..c54f5e32454 100644
>> --- a/arch/arm/mach-socfpga/misc.c
>> +++ b/arch/arm/mach-socfpga/misc.c
>> @@ -178,7 +178,10 @@ int arch_cpu_init(void)
>>    * timeout value is still active which might too short for Linux
>>    * booting.
>>    */
>> +#if !(IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS) || \
>> + IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5_EMU))
>>    hw_watchdog_init();
>> +#endif
>>
>>
>> This is intended for internal use and should be removed.
>>
>>
>>   #else
>>    /*
>>    * If the HW watchdog is NOT enabled, make sure it is not running,
>> @@ -223,8 +226,16 @@ static int do_bridge(struct cmd_tbl *cmdtp, int flag, int argc,
>>
>>   U_BOOT_CMD(bridge, 3, 1, do_bridge,
>>      "SoCFPGA HPS FPGA bridge control",
>> -   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
>> -   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2) bridges\n"
>> +   "enable [mask] - Enable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
>> +   "bridge disable [mask] - Disable HPS-to-FPGA (Bit 0), LWHPS-to-FPGA (Bit 1), FPGA-to-HPS (Bit 2), F2SDRAM0 (Bit 3), F2SDRAM1 (Bit 4), F2SDRAM2 (Bit 5) bridges\n"
>> +   "Bit 3, Bit 4 and Bit 5 bridges only available in Stratix 10\n"
>> +   "For example:\n"
>> +   "1) To enable and disable all bridges (command without mask):\n"
>> +   " a) bridge enable\n"
>> +   " b) bridge disable\n"
>> +   "2) To enable and disable HPS-to-FPGA and LWHPS-to-FPGA bridges (command with mask):\n"
>> +   " a) bridge enable 0x3\n"
>> +   " b) bridge disable 0x3\n"
>>      ""
>>   );
>>
>> @@ -261,6 +272,17 @@ void socfpga_get_managers_addr(void)
>>    if (ret)
>>    hang();
>>
>> + if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {
>>
>>
>> if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
>>          !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M) &&
>>          !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX5)) {
>>
>>
>> The condition for non-Agilex5 platforms should be rewritten because sys-mgr has already moved to the driver model for these platforms.
>>
>>
>> + ret = socfpga_get_base_addr("altr,sys-mgr",
>> +    &socfpga_sysmgr_base);
>> + if (ret)
>> + hang();
>> + }
>> +
>> + if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) ||
>> +    IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M))
>> + ret = socfpga_get_base_addr("intel,agilex-clkmgr",
>> +    &socfpga_clkmgr_base);
>>
>>
>> Similarly, the section for Agilex and Agilex7M using clkmgr can be removed, as both now use the driver model.
>>
>>
>>    else if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))
>>
>>
>> The N5X section should be updated as:  "if (IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X))"
>>
>> The remaining part of the function can remain intact.
>>
>>
>>    ret = socfpga_get_base_addr("intel,n5x-clkmgr",
>>       &socfpga_clkmgr_base);
>>
>>
>> We’ve already tested the above changes and they work as expected.
>>
>>
>> Thanks.
>>
>> Tien Fong

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Sune Brian]

> To clarify, as of today, the driver model has already been implemented
> for Agilex, Agilex7M, and Agilex5. For older SoCFPGA platforms, we will
> ensure that SD boot and existing functionality continue to work while
> maintaining compatibility during this staged migration.

No, there is no ensure that SD boot by just checking what the previous
patch or patches had done.

Simply deleting the most critical line and just feed-in new SoCFPGA required
code breaks the SD boot or possible ROM as well.
And this is not the proper way to patch things.

There is nothing to do with drivers here, in this patch.

So either you revert the old patch or repatch a new patch is your choice.
I had no right and no place to tell Altera what to do, however, simply
breaking mainstream u-boot code is completely unacceptable.

Brian

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Sune Brian]

> like Cyclone V, and Arria 10. Our initial assumption was that users
> would primarily use the Altera official release repo, where we have been
> gradually migrating platform devices to the driver model stage by stage,
> including clk driver used in MMC driver.

Tom, with all respect. I don't see those previous patches really improved
nor introduced a proper build environment for supported SoCFPGA series.

Assumption is not considered as a proper way nor correct way to patch things.
Simply removing critical code and breaking other SoCFPGA families is completely
unacceptable.

We are not talking about code improvement nor cleanup.
What the previous patch actually did is simply remove old generation SoCFPGA
codes and w/o coherently coexist old and new generations.

Brian

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

On Fri, Nov 14, 2025 at 11:35:21PM +0800, Sune Brian wrote:
> > like Cyclone V, and Arria 10. Our initial assumption was that users
> > would primarily use the Altera official release repo, where we have been
> > gradually migrating platform devices to the driver model stage by stage,
> > including clk driver used in MMC driver.
> 
> Tom, with all respect. I don't see those previous patches really improved
> nor introduced a proper build environment for supported SoCFPGA series.
> 
> Assumption is not considered as a proper way nor correct way to patch things.
> Simply removing critical code and breaking other SoCFPGA families is completely
> unacceptable.
> 
> We are not talking about code improvement nor cleanup.
> What the previous patch actually did is simply remove old generation SoCFPGA
> codes and w/o coherently coexist old and new generations.

Something like this recently happened on the i.MX side of things, and it
was fixed because once the rest of the community found out, it was made
clear breaking / removing older used devices is not allowed.

So, Tien, Altera in general, please do whatever is needed to restore
functionality to older devices that are still quite clearly being used
by both the community and your own customers. If more CI of older
targets is needed, get that going. Breaking older devices to support
newer devices is not appropriate.

> 
> Brian

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Chee, Tien Fong]

Hi Tom,

On 15/11/2025 1:35 am, Tom Rini wrote:
>>> like Cyclone V, and Arria 10. Our initial assumption was that users
>>> would primarily use the Altera official release repo, where we have been
>>> gradually migrating platform devices to the driver model stage by stage,
>>> including clk driver used in MMC driver.
>> Tom, with all respect. I don't see those previous patches really improved
>> nor introduced a proper build environment for supported SoCFPGA series.
>>
>> Assumption is not considered as a proper way nor correct way to patch things.
>> Simply removing critical code and breaking other SoCFPGA families is completely
>> unacceptable.
>>
>> We are not talking about code improvement nor cleanup.
>> What the previous patch actually did is simply remove old generation SoCFPGA
>> codes and w/o coherently coexist old and new generations.
> Something like this recently happened on the i.MX side of things, and it
> was fixed because once the rest of the community found out, it was made
> clear breaking / removing older used devices is not allowed.
>
> So, Tien, Altera in general, please do whatever is needed to restore
> functionality to older devices that are still quite clearly being used
> by both the community and your own customers. If more CI of older
> targets is needed, get that going. Breaking older devices to support
> newer devices is not appropriate.


Understood, we will make sure older SoCFPGA platforms (Cyclone V and 
Arria 10) remain fully supported. We'll prepare patches to restore the 
missing functionality and ensure proper coexistence between legacy and 
new driver-model platforms.

We’ll also review our internal CI coverage for older devices to prevent 
similar regressions going forward.

Thanks for highlighting this, we’ll follow up with the fixes.

Regards,
Tien Fong

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Jan Kiszka]

On 17.11.25 08:44, Chee, Tien Fong wrote:
> Hi Tom,
> 
> On 15/11/2025 1:35 am, Tom Rini wrote:
>>>> like Cyclone V, and Arria 10. Our initial assumption was that users
>>>> would primarily use the Altera official release repo, where we have
>>>> been
>>>> gradually migrating platform devices to the driver model stage by
>>>> stage,
>>>> including clk driver used in MMC driver.
>>> Tom, with all respect. I don't see those previous patches really
>>> improved
>>> nor introduced a proper build environment for supported SoCFPGA series.
>>>
>>> Assumption is not considered as a proper way nor correct way to patch
>>> things.
>>> Simply removing critical code and breaking other SoCFPGA families is
>>> completely
>>> unacceptable.
>>>
>>> We are not talking about code improvement nor cleanup.
>>> What the previous patch actually did is simply remove old generation
>>> SoCFPGA
>>> codes and w/o coherently coexist old and new generations.
>> Something like this recently happened on the i.MX side of things, and it
>> was fixed because once the rest of the community found out, it was made
>> clear breaking / removing older used devices is not allowed.
>>
>> So, Tien, Altera in general, please do whatever is needed to restore
>> functionality to older devices that are still quite clearly being used
>> by both the community and your own customers. If more CI of older
>> targets is needed, get that going. Breaking older devices to support
>> newer devices is not appropriate.
> 
> 
> Understood, we will make sure older SoCFPGA platforms (Cyclone V and
> Arria 10) remain fully supported. We'll prepare patches to restore the
> missing functionality and ensure proper coexistence between legacy and
> new driver-model platforms.
> 
> We’ll also review our internal CI coverage for older devices to prevent
> similar regressions going forward.
> 
> Thanks for highlighting this, we’ll follow up with the fixes.
> 

Just discovered this somehow familiar thread, after having spent more 
than a day two weeks ago on the fallouts as well. My patches:

 - https://patchwork.ozlabs.org/project/uboot/patch/99585fee-dd5d-4f9f-aa88-0ee34fe02181@siemens.com/
 - https://patchwork.ozlabs.org/project/uboot/list/?series=482132

I'm all for finding the best technical solution in the end, but I wonder 
if we can at least come to an intermediate solution for the upcoming 
release so that folks do not need to carry too many extra patches in 
their pipelines (https://patchwork.kernel.org/project/cip-dev/patch/cf43e9da3cfc59771e801d3215d3b3794f3602a8.1763446144.git.jan.kiszka@siemens.com/)

Thanks a lot,
Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Sune Brian]

> I'm all for finding the best technical solution in the end, but I wonder
> if we can at least come to an intermediate solution for the upcoming
> release so that folks do not need to carry too many extra patches in
> their pipelines (https://patchwork.kernel.org/project/cip-dev/patch/cf43e9da3cfc59771e801d3215d3b3794f3602a8.1763446144.git.jan.kiszka@siemens.com/)

I am not sure why point to patch v4 but I did provide the final path
version that T.F. should be ok with.
https://patchwork.ozlabs.org/project/uboot/patch/20251114160423.1518-1-briansune@gmail.com/

What this delay is that there are several feature coverage on the same file.
Meanwhile, there are several similar patches pushed and T.F. action time
is a bit slow.

The very first patch was almost two months ago.
https://patchwork.ozlabs.org/project/uboot/patch/20251019092341.1158-1-briansune@gmail.com/

So I had no clue why that huge delay. BTW it is supposed to revert
that pointed out patch to easily fix things.

Brian

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Chee, Tien Fong]

Hi Jan, Brian

On 25/11/2025 6:25 am, Sune Brian wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>
>> I'm all for finding the best technical solution in the end, but I wonder
>> if we can at least come to an intermediate solution for the upcoming
>> release so that folks do not need to carry too many extra patches in
>> their pipelines (https://patchwork.kernel.org/project/cip-dev/patch/cf43e9da3cfc59771e801d3215d3b3794f3602a8.1763446144.git.jan.kiszka@siemens.com/)
> I am not sure why point to patch v4 but I did provide the final path
> version that T.F. should be ok with.
> https://patchwork.ozlabs.org/project/uboot/patch/20251114160423.1518-1-briansune@gmail.com/
>
> What this delay is that there are several feature coverage on the same file.
> Meanwhile, there are several similar patches pushed and T.F. action time
> is a bit slow.
>
> The very first patch was almost two months ago.
> https://patchwork.ozlabs.org/project/uboot/patch/20251019092341.1158-1-briansune@gmail.com/
>
> So I had no clue why that huge delay. BTW it is supposed to revert
> that pointed out patch to easily fix things.
>

Thanks for your patience. We have completed testing with Brian’s patch 
as well as Jan’s patch series, along with a few additional issues we 
identified during integration. We have addressed those issues in our own 
fixes, and we plan to send the patches out for review today.

Brian’s patch:
https://patchwork.ozlabs.org/project/uboot/patch/20251114160423.1518-1-briansune@gmail.com/

Jan’s patch series:
https://patchwork.ozlabs.org/project/uboot/cover/cover.1763140421.git.jan.kiszka@siemens.com/

During our testing, we found an issue in Jan’s series; I will follow up 
separately on those to provide detailed feedback.

Once our patches are posted, we would appreciate your review and 
testing. Please let us know if you spot anything that still needs 
adjustment.

Thanks again,
Tien Fong

Re: [PATCH v4] Altera SoCFpga Boot Stall Fix

[Jan Kiszka]

On 25.11.25 04:10, Chee, Tien Fong wrote:
> Hi Jan, Brian
> 
> On 25/11/2025 6:25 am, Sune Brian wrote:
>> [CAUTION: This email is from outside your organization. Unless you
>> trust the sender, do not click on links or open attachments as it may
>> be a fraudulent email attempting to steal your information and/or
>> compromise your computer.]
>>
>>> I'm all for finding the best technical solution in the end, but I wonder
>>> if we can at least come to an intermediate solution for the upcoming
>>> release so that folks do not need to carry too many extra patches in
>>> their pipelines (https://patchwork.kernel.org/project/cip-dev/patch/
>>> cf43e9da3cfc59771e801d3215d3b3794f3602a8.1763446144.git.jan.kiszka@siemens.com/)
>> I am not sure why point to patch v4 but I did provide the final path
>> version that T.F. should be ok with.
>> https://patchwork.ozlabs.org/project/uboot/
>> patch/20251114160423.1518-1-briansune@gmail.com/

Due to recent discussions in that thread, it floated on top of the
mailing list history for me. No other reasons.

>>
>> What this delay is that there are several feature coverage on the same
>> file.
>> Meanwhile, there are several similar patches pushed and T.F. action time
>> is a bit slow.
>>
>> The very first patch was almost two months ago.
>> https://patchwork.ozlabs.org/project/uboot/
>> patch/20251019092341.1158-1-briansune@gmail.com/
>>
>> So I had no clue why that huge delay. BTW it is supposed to revert
>> that pointed out patch to easily fix things.
>>
> 
> Thanks for your patience. We have completed testing with Brian’s patch
> as well as Jan’s patch series, along with a few additional issues we
> identified during integration. We have addressed those issues in our own
> fixes, and we plan to send the patches out for review today.
> 
> Brian’s patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20251114160423.1518-1-
> briansune@gmail.com/
> 
> Jan’s patch series:
> https://patchwork.ozlabs.org/project/uboot/cover/
> cover.1763140421.git.jan.kiszka@siemens.com/
> 
> During our testing, we found an issue in Jan’s series; I will follow up
> separately on those to provide detailed feedback.
> 
> Once our patches are posted, we would appreciate your review and
> testing. Please let us know if you spot anything that still needs
> adjustment.

I'm happy to test if you CC me, at least on the DE0 Nano SoC then. Also,
please tell us which patches you need updates of or which you would
integrate yourself.

Thanks,
Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center