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

[Yuslaimi, Alif Zakuan]

Hi Brian, Tien Fong,

On 24/2/2026 4:14 pm, Chee, Tien Fong wrote:
> 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
>

Thank you both for your valuable inputs, we can proceed to drop this 
patch as it has been determined that the changes are not relevant - 
there is no need to apply staticcfg bit after controlling the reset for 
F2H bridge.

Best regards,
Alif

>
>