[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