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