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.
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.
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.
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.
Thanks,
Brian
Thanks,
Alif
