[PATCH v1] arm: socfpga: Add call to socfpga_sdram_apply_static_cfg()

[Chee, Tien Fong]

Hi Alif,

On 19/2/2026 10:21 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.]
>
> On Thu, Feb 19, 2026 at 8:18 AM Yuslaimi, Alif Zakuan
> <alif.zakuan.yuslaimi at altera.com> wrote:
>>
>> On 13/2/2026 5:00 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.]
>>>
>>> On Fri, Feb 13, 2026 at 4:44 PM Sune Brian<briansune at gmail.com> wrote:
>>>> On Fri, Feb 13, 2026 at 3:18 PM Yuslaimi, Alif Zakuan
>>>> <alif.zakuan.yuslaimi at altera.com> wrote:
>>>>> Hi Brian,
>>>>>
>>>>> On 6/2/2026 11:09 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 Alif,
>>>>>>
>>>>>> Since 2025.05 to the latest master.
>>>>>> I do not have any issue as you mentioned in this patch.
>>>>>> Both RD/WR are used on the FPGA2SDRAM SDRAM2FPGA.
>>>>>> I tested 256 AXI3 or split 128 AXI3 x2 which is the maximum
>>>>>> that GEN5 Cyclone can support.
>>>>>>
>>>>>> Not too sure what is missing from first place?
>>>>>>
>>>>>> Thanks,
>>>>>> Brian
>>>>> Based on the CycloneV address map which can be found here -
>>>>> https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#sfo1411577374877.html.
>>>>>
>>>>> Bit 3 of staticcfg register has to be set to apply all the settings
>>>>> loaded in SDR registers to the memory interface, in this case the patch
>>>>> ensures the SDRAM controller applies the latest configuration after
>>>>> disabling FPGA SDRAM access.
>>>>>
>>>>> This is a safety and correctness fix for re-initializing the memory
>>>>> controller in the proper sequence during FPGA reconfiguration.
>>>>>
>>>> Hi Alif,
>>>>
>>>> Before I plan to undergo a test we got to understand why w/o this patch
>>>> SDRAM2FPGA works properly w/o issue.
>>>>
>>>>> If you have the time, can you help to test this patch with your setup?
>>>>> Although unlikely, we want to be sure that this patch will not break any
>>>>> existing GEN5 boards out there.
>>>> I might be wrong, I think static cfg has been done already?
>>>> Does the code here if not wrongly understood already finished that static cfg?
>>>>
>>>> ---> Quote start
>>>> void socfpga_sdram_apply_static_cfg(void)
>>>> {
>>>> const u32 applymask = 0x8;
>>>> u32 val = readl(&sdr_ctrl->static_cfg) | applymask;
>>>>
>>>> /*
>>>> * SDRAM staticcfg register specific:
>>>> * When applying the register setting, the CPU must not access
>>>> * SDRAM. Luckily for us, we can use i-cache here to help us
>>>> * circumvent the SDRAM access issue. The idea is to make sure
>>>> * that the code is in one full i-cache line by branching past
>>>> * it and back. Once it is in the i-cache, we execute the core
>>>> * of the code and apply the register settings.
>>>> *
>>>> * The code below uses 7 instructions, while the Cortex-A9 has
>>>> * 32-byte cachelines, thus the limit is 8 instructions total.
>>>> */
>>>> asm volatile(".align 5 \n"
>>>>        " b 2f \n"
>>>>        "1: str %0, [%1] \n"
>>>>        " dsb \n"
>>>>        " isb \n"
>>>>        " b 3f \n"
>>>>        "2: b 1b \n"
>>>>        "3: nop \n"
>>>>       : : "r"(val), "r"(&sdr_ctrl->static_cfg) : "memory", "cc");
>>>> }
>>>> Quote end<---
>>>>
>>> I forgot to quote the func call location:
>>>
>>> void do_bridge_reset(int enable, unsigned int mask)
>>>
>>> During boot users are supposed to use bridge enable to
>>> control the needs of the HPS <-> SDRAM or H2F F2H LW etc.
>>> When calls if I am not wrongly understand it will reset and
>>> simply do that static cfg and simply do not require additional
>>> calls.
>>>
>> Thanks for pointing this out, Brian.
>>
> Hi Alif,
>
> Pic by pic.
>
>> I understand that you saw potential redundancy in this patch's explicit
>> re-application of the SDRAM static configuration, which may already be
>> handled by the existing call to socfpga_sdram_apply_static_cfg() during
>> bridge reset.
> This is following the old boot flow to the latest and not having issues
> under boot.scr with "bridge enable" and sub-bit bridge setup.
>
>> I would imagine your current flow works as the current code already
>> applies SDRAM configuration changes at the correct time during boot or
>> bridge reset. However, there are some cases or sequences where this
>> apply step could be missed - such as during partial reconfiguration.
> Not too understand this case even if you PR the bridge enable MUST
> be done after the reconfiguration phase aka "bridge enable".
> And PR itself has nothing to do with turning on F2H SDRAM the first time.
> One is the FPGA manager and the other is the HPS register unless it auto
> reset all bridge registers.
> I can also reload full bit during boot again and again and boot to linux w/o
> f2h issue.
>
>> This patch would then be needed as an extra safeguard in cases where SDR
>> registers are updated manually or outside the typical bridge reset sequence.
> If the user doesn't use f2h then turning on this bit for what purpose?
> As "bridge
> enable" under boot.scr have good control.


NAK as the TRM’s staticcfg.applycfg (bit 3) applies SDRAM-controller 
configuration to the memory interface (burst length membl, ECC/data 
width, timings, etc.).

It does not gate fpgaportrst.portrstn. The claim “after write to any SDR 
register” is too broad.

fpgaportrst.portrstn[13:0] is a live reset control for the FPGA ports.  
Writing 0 stretches reset, writing 1 releases reset. Its effect is 
immediate and independent of applycfg.

Thanks.

Best regards,

Tien Fong