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
<[email protected]> 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<[email protected]> wrote:
On Fri, Feb 13, 2026 at 3:18 PM Yuslaimi, Alif Zakuan
<[email protected]> 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
