[PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Brian Sune]

New SPL introduce cyclic and without initial
the interrupt of SDRAM calibration could fail.
Initialize the default CYCLIC setup fix it.

Signed-off-by: Brian Sune <briansune@gmail.com>
---
 arch/arm/mach-socfpga/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index f2e959b5662..1f536c7ea74 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -117,6 +117,8 @@ config TARGET_SOCFPGA_CYCLONE5
 
 config TARGET_SOCFPGA_GEN5
 	bool
+	select CYCLIC
+	select SPL_CYCLIC
 	select SPL_ALTERA_SDRAM
 	imply FPGA_SOCFPGA
 	imply SPL_SIZE_LIMIT_SUBTRACT_GD
-- 
2.34.1

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> +       select CYCLIC
> +       select SPL_CYCLIC
>         select SPL_ALTERA_SDRAM
>         imply FPGA_SOCFPGA
>         imply SPL_SIZE_LIMIT_SUBTRACT_GD

Hi Quentin,

But interestingly do you tried any case that when defconfig
had given
CONFIG_CYCLIC=y
CONFIG_SPL_CYCLIC=y
but empty CMD_CYCLIC?

What my observation is that it is automatically turn on
CMD_CYCLIC during .config recovery.

So I had no clue what you want on this correlated settings.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Quentin Schulz]

Hi Brian,

On 11/25/25 10:47 PM, Sune Brian wrote:
>> +       select CYCLIC
>> +       select SPL_CYCLIC
>>          select SPL_ALTERA_SDRAM
>>          imply FPGA_SOCFPGA
>>          imply SPL_SIZE_LIMIT_SUBTRACT_GD
> 
> Hi Quentin,
> 
> But interestingly do you tried any case that when defconfig
> had given
> CONFIG_CYCLIC=y
> CONFIG_SPL_CYCLIC=y
> but empty CMD_CYCLIC?
> 
> What my observation is that it is automatically turn on
> CMD_CYCLIC during .config recovery.
> 
> So I had no clue what you want on this correlated settings.

CMD_CYCLIC is enabled by default ("default y") if its dependencies are 
met (that is "CYCLIC" as specified by "depends on CYCLIC" in 
cmd/Kconfig). So when you enable CONFIG_CYCLIC via menuconfig, it 
enables (by default) CMD_CYCLIC as well. But you can disable it if you 
don't need it for example. If you add a "select OPTION" in an option in 
Kconfig, you cannot disable OPTION anymore.

CMD_CYCLIC is not required, so you shouldn't "depends on" or "select" it.

Cheers,
Quentin

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> CMD_CYCLIC is enabled by default ("default y") if its dependencies are
> met (that is "CYCLIC" as specified by "depends on CYCLIC" in
> cmd/Kconfig). So when you enable CONFIG_CYCLIC via menuconfig, it
> enables (by default) CMD_CYCLIC as well. But you can disable it if you
> don't need it for example. If you add a "select OPTION" in an option in
> Kconfig, you cannot disable OPTION anymore.
>
> CMD_CYCLIC is not required, so you shouldn't "depends on" or "select" it.

Yes this patch had removed it by cross-check via real board on the fail
calibration issue. But CYCLIC and CYCLIC_SPL still a must to fix the issue.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Hi all

> > CMD_CYCLIC is enabled by default ("default y") if its dependencies are
> > met (that is "CYCLIC" as specified by "depends on CYCLIC" in
> > cmd/Kconfig). So when you enable CONFIG_CYCLIC via menuconfig, it
> > enables (by default) CMD_CYCLIC as well. But you can disable it if you
> > don't need it for example. If you add a "select OPTION" in an option in
> > Kconfig, you cannot disable OPTION anymore.
> >
> > CMD_CYCLIC is not required, so you shouldn't "depends on" or "select" it.
>
> Yes this patch had removed it by cross-check via real board on the fail
> calibration issue. But CYCLIC and CYCLIC_SPL still a must to fix the issue.
>
> Brian

Would Altera also confirm this issue a bit?
I can repeat this issue by a fresh pull build.

Thanks,
Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Chee, Tien Fong]

Hi Brian,

On 28/11/2025 6:04 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.]
>
> Hi all
>
>>> CMD_CYCLIC is enabled by default ("default y") if its dependencies are
>>> met (that is "CYCLIC" as specified by "depends on CYCLIC" in
>>> cmd/Kconfig). So when you enable CONFIG_CYCLIC via menuconfig, it
>>> enables (by default) CMD_CYCLIC as well. But you can disable it if you
>>> don't need it for example. If you add a "select OPTION" in an option in
>>> Kconfig, you cannot disable OPTION anymore.
>>>
>>> CMD_CYCLIC is not required, so you shouldn't "depends on" or "select" it.
>> Yes this patch had removed it by cross-check via real board on the fail
>> calibration issue. But CYCLIC and CYCLIC_SPL still a must to fix the issue.
>>
>> Brian
> Would Altera also confirm this issue a bit?
> I can repeat this issue by a fresh pull build.

Thanks for sharing your findings. However, based on the behavior you 
described, I’m not fully convinced that enabling cyclic/watchdog is 
actually fixing the SDRAM calibration issue itself. From the SPL side, 
there is no clear timeout or calibration control path that would 
logically be corrected by turning on the cyclic framework, so the 
improvement may simply be due to timing shifts rather than a real fix.

Before we go deeper into upstream work, could you try testing against 
the official Altera downstream tree?

Altera official U-Boot (SoCFPGA):
https://github.com/altera-fpga/u-boot-socfpga - branch socfpga_v2025.07

This branch includes several Gen5 DDR related fixes that are not 
upstreamed yet. If calibration becomes stable with the downstream tree, 
then it is very likely that the real fix already exists there, and we 
can identify which patch addresses the root cause instead of spending 
time reverse engineering a solution that may already be solved.

If the calibration still fails even on the official release, then at 
least we can rule out downstream fixes and focus efforts on the correct 
upstream location.

Let me know the results, it will help us pinpoint whether the issue is 
timing-related or missing a specific patch.

Thanks.

Tien Fong

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> Altera official U-Boot (SoCFPGA):
> https://github.com/altera-fpga/u-boot-socfpga - branch socfpga_v2025.07
>

Confirm downstream on default cyclone v socdk always works stable.
No settings are touch nor any file are modified.

What other confirmations are required?

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> Thanks for sharing your findings. However, based on the behavior you
> described, I’m not fully convinced that enabling cyclic/watchdog is
> actually fixing the SDRAM calibration issue itself. From the SPL side,
> there is no clear timeout or calibration control path that would
> logically be corrected by turning on the cyclic framework, so the
> improvement may simply be due to timing shifts rather than a real fix.

BTW T.F. I want to point out a very important setup.
By default the Altera trunk had turned on

  │ │       [*] Enable U-Boot watchdog reset
                   │ │
  │ │       [*] Automatically start watchdog timer
                   │ │
  │ │       (10000) Watchdog timeout in msec
                   │ │
  │ │       [ ] Enable Watchdog Timer support for IMX and LSCH2 of NXP
                   │ │
  │ │       [ ] i.MX7ULP watchdog
                   │ │
  │ │       -*- Designware watchdog timer support
                   │ │
  │ │       [*] Enable driver model for watchdog timer drivers

So maybe you can also reverse investigate on your side via real board.
Removing all CYCLIC WDT drivers and all dst watchdog "okay" do
not introduce sdram calibration issue?

Lets cross check.

Thanks,
Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> BTW T.F. I want to point out a very important setup.
> By default the Altera trunk had turned on
>
>   │ │       [*] Enable U-Boot watchdog reset
>                    │ │
>   │ │       [*] Automatically start watchdog timer
>                    │ │
>   │ │       (10000) Watchdog timeout in msec
>                    │ │
>   │ │       [ ] Enable Watchdog Timer support for IMX and LSCH2 of NXP
>                    │ │
>   │ │       [ ] i.MX7ULP watchdog
>                    │ │
>   │ │       -*- Designware watchdog timer support
>                    │ │
>   │ │       [*] Enable driver model for watchdog timer drivers
>
> So maybe you can also reverse investigate on your side via real board.
> Removing all CYCLIC WDT drivers and all dst watchdog "okay" do
> not introduce sdram calibration issue?
>
> Lets cross check.

Hi T.F. and adding Alif as well.

Long story short it fails on Altera trunk as follow:
1: Altera trunk force enable the driver of DESIGNWARE_WATCHDOG
2: It is not allow to remove by default git pull
3: After manually remove via Kconfig modification

config TARGET_SOCFPGA_GEN5
bool
# select DESIGNWARE_WATCHDOG

4: The DESIGNWARE and all CYCLIC are turned off

DTS, .config had double confirmed the setup

Test result:

U-Boot SPL 2025.07-g35abb4f1cedc-dirty (Nov 28 2025 - 20:19:39 +0800)
SDRAM calibration failed.
### ERROR ### Please RESET the board ###

Long story short the inherent patch for this series is actually correct.
The WDT introduces calibration failures.

Thanks,
Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Chee, Tien Fong <tienfong.chee@altera.com> 於 2025年11月28日週五 下午6:17寫道：
>
> Hi Brian,
>
> On 28/11/2025 6:04 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.]
> >
> > Hi all
> >
> >>> CMD_CYCLIC is enabled by default ("default y") if its dependencies are
> >>> met (that is "CYCLIC" as specified by "depends on CYCLIC" in
> >>> cmd/Kconfig). So when you enable CONFIG_CYCLIC via menuconfig, it
> >>> enables (by default) CMD_CYCLIC as well. But you can disable it if you
> >>> don't need it for example. If you add a "select OPTION" in an option in
> >>> Kconfig, you cannot disable OPTION anymore.
> >>>
> >>> CMD_CYCLIC is not required, so you shouldn't "depends on" or "select" it.
> >> Yes this patch had removed it by cross-check via real board on the fail
> >> calibration issue. But CYCLIC and CYCLIC_SPL still a must to fix the issue.
> >>
> >> Brian
> > Would Altera also confirm this issue a bit?
> > I can repeat this issue by a fresh pull build.
>
> Thanks for sharing your findings. However, based on the behavior you
> described, I’m not fully convinced that enabling cyclic/watchdog is
> actually fixing the SDRAM calibration issue itself. From the SPL side,
> there is no clear timeout or calibration control path that would
> logically be corrected by turning on the cyclic framework, so the
> improvement may simply be due to timing shifts rather than a real fix.
>
> Before we go deeper into upstream work, could you try testing against
> the official Altera downstream tree?
>
> Altera official U-Boot (SoCFPGA):
> https://github.com/altera-fpga/u-boot-socfpga - branch socfpga_v2025.07
>
> This branch includes several Gen5 DDR related fixes that are not
> upstreamed yet. If calibration becomes stable with the downstream tree,
> then it is very likely that the real fix already exists there, and we
> can identify which patch addresses the root cause instead of spending
> time reverse engineering a solution that may already be solved.
>
> If the calibration still fails even on the official release, then at
> least we can rule out downstream fixes and focus efforts on the correct
> upstream location.
>
> Let me know the results, it will help us pinpoint whether the issue is
> timing-related or missing a specific patch.
>
> Thanks.
>
> Tien Fong
>

Hi T.F.

I am enclosing a bit log here.
I had diff both sequencer on mainstream and altera trunk.
No diff.

As for the sdram_gen5.c there are diff but no major point
before calibration fail is trigger. ECC is not use or setup.

Setup:
No CYCLIC no WDT all off on dts and .config.
No modification on code.
The below logs are trigger via reset key.

Pass case:
U-Boot SPL 2026.01-rc3-00043-gd5276409c0a1-dirty (Dec 01 2025 - 21:10:15 +0800)
sequencer: Preparing to start memory calibration
sdram_calibration_full:3939
run_mem_calibrate:3671
phy_mgr_initialize:115
rw_mgr_mem_initialize:1048
delay_for_n_mem_clocks:809: clocks=250 ... start
delay_for_n_mem_clocks:872 clocks=250 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=512 ... start
delay_for_n_mem_clocks:872 clocks=512 ... end
mem_calibrate:3492
mem_init_latency:3358
rw_mgr_mem_calibrate_vfifo:2853: 0 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
rw_mgr_mem_calibrate_vfifo_center:2565: 0 0rw_mgr_mem_calibrate_writes:3295 0 0
rw_mgr_mem_calibrate_writes_center:3146 0
0rw_mgr_mem_calibrate_vfifo_end:2950 0
0rw_mgr_mem_calibrate_vfifo_center:2565: 0
0rw_mgr_mem_calibrate_vfifo:2853: 1 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (1,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 1
rw_mgr_mem_calibrate_vfifo_center:2565: 1 0rw_mgr_mem_calibrate_writes:3295 1 8
rw_mgr_mem_calibrate_writes_center:3146 1
8rw_mgr_mem_calibrate_vfifo_end:2950 1
0rw_mgr_mem_calibrate_vfifo_center:2565: 1
0rw_mgr_mem_calibrate_vfifo:2853: 2 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (2,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 2
rw_mgr_mem_calibrate_vfifo_center:2565: 2 0rw_mgr_mem_calibrate_writes:3295 2 16
rw_mgr_mem_calibrate_writes_center:3146 2
16rw_mgr_mem_calibrate_vfifo_end:2950 2
0rw_mgr_mem_calibrate_vfifo_center:2565: 2
0rw_mgr_mem_calibrate_vfifo:2853: 3 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (3,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 3
rw_mgr_mem_calibrate_vfifo_center:2565: 3 0rw_mgr_mem_calibrate_writes:3295 3 24
rw_mgr_mem_calibrate_writes_center:3146 3
24rw_mgr_mem_calibrate_vfifo_end:2950 3
0rw_mgr_mem_calibrate_vfifo_center:2565: 3
0rw_mgr_mem_calibrate_lfifo:2979
rw_mgr_mem_calibrate_read_load_patterns:1446
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
sequencer: CALIBRATION PASSED
sequencer: Calibration complete
Trying to boot from MMC1

Fail case:
U-Boot SPL 2026.01-rc3-00043-gd5276409c0a1-dirty (Dec 01 2025 - 21:10:15 +0800)
sequencer: Preparing to start memory calibration
sdram_calibration_full:3939
run_mem_calibrate:3671
phy_mgr_initialize:115
rw_mgr_mem_initialize:1048
delay_for_n_mem_clocks:809: clocks=250 ... start
delay_for_n_mem_clocks:872 clocks=250 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=512 ... start
delay_for_n_mem_clocks:872 clocks=512 ... end
mem_calibrate:3492
mem_init_latency:3358
rw_mgr_mem_calibrate_vfifo:2853: 0 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
rw_mgr_mem_calibrate_read_load_patterns:1446
rw_mgr_mem_calibrate_dqs_enable_calibration:2747 (0,0)
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1959 0
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
delay_for_n_mem_clocks:809: clocks=4 ... start
delay_for_n_mem_clocks:872 clocks=4 ... end
sequencer: CALIBRATION FAILED
sequencer: Calibration complete
SDRAM calibration failed.
### ERROR ### Please RESET the board ###

Thanks,
Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

Hi Brian,

On Mon, Dec 1, 2025 at 8:24 AM Sune Brian <briansune@gmail.com> wrote:
> I am enclosing a bit log here.
> I had diff both sequencer on mainstream and altera trunk.
> No diff.
>
> As for the sdram_gen5.c there are diff but no major point
> before calibration fail is trigger. ECC is not use or setup.
>
> Setup:
> No CYCLIC no WDT all off on dts and .config.
> No modification on code.

I had similar problem on a custom board with cyclone V. I tried
disabling the watchdog but this didn't make any difference.

After bisecting, I traced it to commit 3b8dfc42a23 which changed
CONFIG_SYS_TIMER_COUNTS_DOWN into a real Kconfig symbol. Although this
was updated in socfpga_cyclone5_defconfig, I had to make the same
change in my defconfig.

Not sure if this is your problem too, but worth checking, particularly
if you're using a custom defconfig.

Regards,
Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Ralph Siemsen <ralph.siemsen@linaro.org> 於 2025年12月4日週四 上午2:01寫道：
>
> Hi Brian,
>
> On Mon, Dec 1, 2025 at 8:24 AM Sune Brian <briansune@gmail.com> wrote:
> > I am enclosing a bit log here.
> > I had diff both sequencer on mainstream and altera trunk.
> > No diff.
> >
> > As for the sdram_gen5.c there are diff but no major point
> > before calibration fail is trigger. ECC is not use or setup.
> >
> > Setup:
> > No CYCLIC no WDT all off on dts and .config.
> > No modification on code.
>
> I had similar problem on a custom board with cyclone V. I tried
> disabling the watchdog but this didn't make any difference.

Hi Ralph,

But did you disable also all "CYCLIC" as well?

>
> After bisecting, I traced it to commit 3b8dfc42a23 which changed
> CONFIG_SYS_TIMER_COUNTS_DOWN into a real Kconfig symbol. Although this

1) If my memory recall correctly just after this week bundle merge of GEN5.
The issue cont'd exist after disable all WDT CYCLIC etc.

2) This is still a bit contradict what T.F. mentioned.
If anything that is related to the time or counter then the original
susception holds.

3) I use socfpga_cyclone5_defconfig and only change minimum settings
that I needs.
From this issue mentioned to current day.

> was updated in socfpga_cyclone5_defconfig, I had to make the same
> change in my defconfig.
>
> Not sure if this is your problem too, but worth checking, particularly
> if you're using a custom defconfig.
>
> Regards,
> Ralph

Still thank you and I will check.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

Hi Brian,

On Wed, Dec 3, 2025 at 1:17 PM Sune Brian <briansune@gmail.com> wrote:

> But did you disable also all "CYCLIC" as well?

I have "CONFIG_CYCLIC is not set" which disables all the others.

I also have another patch to disable the watchdog, adapted from [1].
This didn't seem to make any difference (but my ram calibration
doesn't take very long).

[1]  https://lore.kernel.org/all/20250603115442.19971-8-nareshkumar.ravulapalli@altera.com/

> 3) I use socfpga_cyclone5_defconfig and only change minimum settings
> that I needs.
> From this issue mentioned to current day.

Then it sounds like it is a recent issue... hmm... I'm currently on
2025.10 release version (plus some cherry-picks). I'll give a try on
master/next once I get some other things stabilised...

Regards,
Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Ralph Siemsen <ralph.siemsen@linaro.org> 於 2025年12月4日週四 上午4:52寫道：
>
> Hi Brian,
>
> On Wed, Dec 3, 2025 at 1:17 PM Sune Brian <briansune@gmail.com> wrote:
>
> > But did you disable also all "CYCLIC" as well?
>
> I have "CONFIG_CYCLIC is not set" which disables all the others.
>
> I also have another patch to disable the watchdog, adapted from [1].
> This didn't seem to make any difference (but my ram calibration
> doesn't take very long).
>
> [1]  https://lore.kernel.org/all/20250603115442.19971-8-nareshkumar.ravulapalli@altera.com/
>

Hi Ralph,

I do diff the mainstream and Altera trunk.
I cam repeat the same behavior on altera trunk when all WDT CYCLIC turned off.

I plan to investigate under another board.
TBH if it is board specific case then there is nothing harm to simply
turn on CYCLIC or WDT.
But the truth is that Altera trunk force using designware WDT by default.
Because under distro I do full "memtester" and "stressapptest".
Nothing really fails on those two.

> > 3) I use socfpga_cyclone5_defconfig and only change minimum settings
> > that I needs.
> > From this issue mentioned to current day.
>
> Then it sounds like it is a recent issue... hmm... I'm currently on
> 2025.10 release version (plus some cherry-picks). I'll give a try on
> master/next once I get some other things stabilised...
>
> Regards,
> Ralph

The major reason is the ECC on mainstream is completely missing.
BTW [1] I do manually inserted and test no luck on that.

Yet still thank you for the help.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Yuslaimi, Alif Zakuan]

Hi,

On 4/12/2025 5:02 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.]
> 
> Ralph Siemsen <ralph.siemsen@linaro.org> 於 2025年12月4日週四 上午4:52寫道：
>>
>> Hi Brian,
>>
>> On Wed, Dec 3, 2025 at 1:17 PM Sune Brian <briansune@gmail.com> wrote:
>>
>>> But did you disable also all "CYCLIC" as well?
>>
>> I have "CONFIG_CYCLIC is not set" which disables all the others.
>>
>> I also have another patch to disable the watchdog, adapted from [1].
>> This didn't seem to make any difference (but my ram calibration
>> doesn't take very long).
>>
>> [1]  https://lore.kernel.org/all/20250603115442.19971-8-nareshkumar.ravulapalli@altera.com/
>>
> 
> Hi Ralph,
> 
> I do diff the mainstream and Altera trunk.
> I cam repeat the same behavior on altera trunk when all WDT CYCLIC turned off.
> 
> I plan to investigate under another board.
> TBH if it is board specific case then there is nothing harm to simply
> turn on CYCLIC or WDT.
> But the truth is that Altera trunk force using designware WDT by default.
> Because under distro I do full "memtester" and "stressapptest".
> Nothing really fails on those two.
> 

I have tried to disable all WDT and CYCLIC configs on both Altera trunk 
and mainline U-Boot on my side.

I made some changes to the standard socfpga_cyclone5_defconfig as well 
as the common Kconfig to really disable all watchdog configs.

I cannot replicate the issue on both cases, I am able to boot via RAM 
through ARM debugger, as well as through MMC boot after triggering reset 
in Linux.

I am using our Cyclone V SoC Development Kit, details of the board can 
be found here

[1] 
https://www.rocketboards.org/foswiki/Documentation/AlteraSoCDevelopmentBoard

I am thinking this could be related to the power supply not being fully 
stable before SDRAM calibration, perhaps you could try other reset 
methods, such as cold/warm reset, or power cycling the board and see if 
there is any difference compared to using the physical reset switch key?

Thanks,
Alif

>>> 3) I use socfpga_cyclone5_defconfig and only change minimum settings
>>> that I needs.
>>>  From this issue mentioned to current day.
>>
>> Then it sounds like it is a recent issue... hmm... I'm currently on
>> 2025.10 release version (plus some cherry-picks). I'll give a try on
>> master/next once I get some other things stabilised...
>>
>> Regards,
>> Ralph
> 
> The major reason is the ECC on mainstream is completely missing.
> BTW [1] I do manually inserted and test no luck on that.
> 
> Yet still thank you for the help.
> 
> Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Yuslaimi, Alif Zakuan <alif.zakuan.yuslaimi@altera.com> 於 2025年12月4日週四 上午9:11寫道：
>
> Hi,
>
> On 4/12/2025 5:02 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.]
> >
> > Ralph Siemsen <ralph.siemsen@linaro.org> 於 2025年12月4日週四 上午4:52寫道：
> >>
> >> Hi Brian,
> >>
> >> On Wed, Dec 3, 2025 at 1:17 PM Sune Brian <briansune@gmail.com> wrote:
> >>
> >>> But did you disable also all "CYCLIC" as well?
> >>
> >> I have "CONFIG_CYCLIC is not set" which disables all the others.
> >>
> >> I also have another patch to disable the watchdog, adapted from [1].
> >> This didn't seem to make any difference (but my ram calibration
> >> doesn't take very long).
> >>
> >> [1]  https://lore.kernel.org/all/20250603115442.19971-8-nareshkumar.ravulapalli@altera.com/
> >>
> >
> > Hi Ralph,
> >
> > I do diff the mainstream and Altera trunk.
> > I cam repeat the same behavior on altera trunk when all WDT CYCLIC turned off.
> >
> > I plan to investigate under another board.
> > TBH if it is board specific case then there is nothing harm to simply
> > turn on CYCLIC or WDT.
> > But the truth is that Altera trunk force using designware WDT by default.
> > Because under distro I do full "memtester" and "stressapptest".
> > Nothing really fails on those two.
> >
>
> I have tried to disable all WDT and CYCLIC configs on both Altera trunk
> and mainline U-Boot on my side.
>
> I made some changes to the standard socfpga_cyclone5_defconfig as well
> as the common Kconfig to really disable all watchdog configs.
>
> I cannot replicate the issue on both cases, I am able to boot via RAM
> through ARM debugger, as well as through MMC boot after triggering reset
> in Linux.
>
> I am using our Cyclone V SoC Development Kit, details of the board can
> be found here
>
> [1]
> https://www.rocketboards.org/foswiki/Documentation/AlteraSoCDevelopmentBoard
>
> I am thinking this could be related to the power supply not being fully
> stable before SDRAM calibration, perhaps you could try other reset
> methods, such as cold/warm reset, or power cycling the board and see if
> there is any difference compared to using the physical reset switch key?
>
> Thanks,
> Alif
>
> >>> 3) I use socfpga_cyclone5_defconfig and only change minimum settings
> >>> that I needs.
> >>>  From this issue mentioned to current day.
> >>
> >> Then it sounds like it is a recent issue... hmm... I'm currently on
> >> 2025.10 release version (plus some cherry-picks). I'll give a try on
> >> master/next once I get some other things stabilised...
> >>
> >> Regards,
> >> Ralph
> >
> > The major reason is the ECC on mainstream is completely missing.
> > BTW [1] I do manually inserted and test no luck on that.
> >
> > Yet still thank you for the help.
> >
> > Brian
>

Hi Alif,

I think almost 90% or even 95% above board only uses 1GB socdk as well.
I am undergoing a deep investigation.
Cyclone V SoC FPGA boards also do
not have issues w/o WDT CYCLIC.
The issue happened on 2GB variant boards.

If any parties or users happen to have 2GB please do point out it is
OK.

If not it is a 32bit bug on driver or other files.
Calibration time is indeed longer.

No time shift is not a solution or inherent problem here.
2x512x16 ddr die is used to introduce a signed possible issue perhase.
aka 0x8000_0000

Thanks,
Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

On Wed, Dec 3, 2025 at 3:52 PM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
> Then it sounds like it is a recent issue... hmm... I'm currently on
> 2025.10 release version (plus some cherry-picks). I'll give a try on
> master/next once I get some other things stabilised...

Just a quick note to say that master branch (with Jan's v2 patches) is
working fine for me. The calibration is passing on both cold/warm
reboot, as well as power cycling (I tried a few dozen times each).
Note that my board only has 512 MB.

Regards,
Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Ralph Siemsen <ralph.siemsen@linaro.org> 於 2025年12月4日週四 下午11:47寫道：
>
> On Wed, Dec 3, 2025 at 3:52 PM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
> > Then it sounds like it is a recent issue... hmm... I'm currently on
> > 2025.10 release version (plus some cherry-picks). I'll give a try on
> > master/next once I get some other things stabilised...
>
> Just a quick note to say that master branch (with Jan's v2 patches) is
> working fine for me. The calibration is passing on both cold/warm
> reboot, as well as power cycling (I tried a few dozen times each).
> Note that my board only has 512 MB.

Thank you. Yet, no confirmation on 2GB situation. For 1G or 512M
I can also repeat normal boot on different brand.
Which for 512x16 ddr3 die can have several construction from the beginning.
But the question still holds "WHY" CYCLIC or WDT can trigger a normal boot?
Cannot explain nor trace.

Brian

>
> Regards,
> Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Hi Tom,

Tom please reject his patch, thank you.

Hi Alif, and Ralph,

As you both had undergo a board test.
First sorry for cont'd bothering both of you.

If possible I would like to check if this is aligned disregarded to DRAM size.
On U-Boot latest or after 2025.07.

Issue 1:
sequencer.c if turned on debug by including this at the very top.
"#define LOG_DEBUG" and "#define DLEVEL 1 or 2"
If will stall somehow on any brand of board my side current had.

Issue 2:
For DRAM size larger than 1GB, when w/o O.C. and using as stable
setting as possible.
Even it passed the calibration it will not cont'd boot when
sdram_gen5.c is turned on debug flag via "#define LOG_DEBUG"
However this issue is not found on 1GB nor 512MB.

Finding 1:
This is very puzzling and completely lost control on what possible cause.
If SDRAM fails same WDT or CYCLIC simply bypassed it.
Aka 533MHz DRAM speed then it is a must to discover bitflip or any issue
under distro test tools "memtester" or "stressapptest" on long sanity test.
However neither of those return issue since the board used for development.

Finding 2
So long story short WDT or CYCLIC is not a solution to fix SDRAM
calibration fail.

Thanks,
Brian

> > On Wed, Dec 3, 2025 at 3:52 PM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
> > > Then it sounds like it is a recent issue... hmm... I'm currently on
> > > 2025.10 release version (plus some cherry-picks). I'll give a try on
> > > master/next once I get some other things stabilised...
> >
> > Just a quick note to say that master branch (with Jan's v2 patches) is
> > working fine for me. The calibration is passing on both cold/warm
> > reboot, as well as power cycling (I tried a few dozen times each).
> > Note that my board only has 512 MB.
>
> Thank you. Yet, no confirmation on 2GB situation. For 1G or 512M
> I can also repeat normal boot on different brand.
> Which for 512x16 ddr3 die can have several construction from the beginning.
> But the question still holds "WHY" CYCLIC or WDT can trigger a normal boot?
> Cannot explain nor trace.
>
> Brian
>
> >
> > Regards,
> > Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

Hi Brian,

On Thu, Dec 4, 2025 at 1:09 PM Sune Brian <briansune@gmail.com> wrote:

> If possible I would like to check if this is aligned disregarded to DRAM size.
> On U-Boot latest or after 2025.07.

Sorry for the delay. I am testing on 2025.10 version with a few
additional changes. It is a custom board using its own Quartus memory
parameters (which have been unchanged in many years).

> Issue 1:
> sequencer.c if turned on debug by including this at the very top.
> "#define LOG_DEBUG" and "#define DLEVEL 1 or 2"
> If will stall somehow on any brand of board my side current had.

I also encountered this, but it was solved by disable the watchdog, by
toggling L4WD0 reset. After doing this, there is no problem with using
DLEVEL 2. I even took it a step further and logged every single write
to the DDR control registers.

> Issue 2:
> For DRAM size larger than 1GB, when w/o O.C. and using as stable
> setting as possible.
> Even it passed the calibration it will not cont'd boot when
> sdram_gen5.c is turned on debug flag via "#define LOG_DEBUG"
> However this issue is not found on 1GB nor 512MB.

I was able to get access to board with 2GB, and it boots successfully.
Memory calibration completes, and subsequent test with u-boot "mtest"
basic memory test is also passing.

I'm also running memtester on my 512MB board and it hasn't found any
issues after a few hours runtime.

Regards,
Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Hi Ralph,

On Fri, Dec 12, 2025 at 1:36 AM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> Hi Brian,
>
> On Thu, Dec 4, 2025 at 1:09 PM Sune Brian <briansune@gmail.com> wrote:
>
> > If possible I would like to check if this is aligned disregarded to DRAM size.
> > On U-Boot latest or after 2025.07.
>
> Sorry for the delay. I am testing on 2025.10 version with a few
> additional changes. It is a custom board using its own Quartus memory
> parameters (which have been unchanged in many years).
>
> > Issue 1:
> > sequencer.c if turned on debug by including this at the very top.
> > "#define LOG_DEBUG" and "#define DLEVEL 1 or 2"
> > If will stall somehow on any brand of board my side current had.
>
> I also encountered this, but it was solved by disable the watchdog, by
> toggling L4WD0 reset. After doing this, there is no problem with using
> DLEVEL 2. I even took it a step further and logged every single write
> to the DDR control registers.

For issue 1 it is just a debug issue but I could also try a bit of your method.
Didn't deeply investigate this.

>
> > Issue 2:
> > For DRAM size larger than 1GB, when w/o O.C. and using as stable
> > setting as possible.
> > Even it passed the calibration it will not cont'd boot when
> > sdram_gen5.c is turned on debug flag via "#define LOG_DEBUG"
> > However this issue is not found on 1GB nor 512MB.
>
> I was able to get access to board with 2GB, and it boots successfully.
> Memory calibration completes, and subsequent test with u-boot "mtest"
> basic memory test is also passing.

For your 2GB case it is w/o CYCLIC and WDT right?
For this may I ask what DDR3 speed you used? 400MHz?
For 2GB there are different die configurations 512x16 itself also come with
different forms. If possible can you provide the actual die part #?

For the latest test result.
1) all boards can run properly w/o watchdog or cyclic but only works on
400M on any size from 512M to 2G.
2) For die itself it is shown that twice die performs much more stably.
3) The DDR calibration itself is so touchy on time and opening CYCLIC or
WDT highly improves the bootup stability on all timing bins.

>
> I'm also running memtester on my 512MB board and it hasn't found any
> issues after a few hours runtime.
>

The most puzzling part is this. It only dies on the U-Boot stage.
The ddr sequence.c was somehow cropped to a point for only size and
speed for the file comments.
All boards or cases that even by luck passed the calibration phase on U-Boot
do not have any issue on all stressapptest nor memtester under distro.

> Regards,
> Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

On Thu, Dec 11, 2025 at 2:15 PM Sune Brian <briansune@gmail.com> wrote:
>
> > > Issue 2:
> > > For DRAM size larger than 1GB, when w/o O.C. and using as stable
> > > setting as possible.
> > > Even it passed the calibration it will not cont'd boot when
> > > sdram_gen5.c is turned on debug flag via "#define LOG_DEBUG"
> > > However this issue is not found on 1GB nor 512MB.
> >
> > I was able to get access to board with 2GB, and it boots successfully.
> > Memory calibration completes, and subsequent test with u-boot "mtest"
> > basic memory test is also passing.
>
> For your 2GB case it is w/o CYCLIC and WDT right?

Correct. Both my 512MB and 2GB are without CYCLIC and WDT.

> For this may I ask what DDR3 speed you used? 400MHz?

Yes, it is 400MHz, at least on the 512MB board.

> For 2GB there are different die configurations 512x16 itself also come with
> different forms. If possible can you provide the actual die part #?

Unfortunately I don't have physical access (nor schematics) to check that.

> The most puzzling part is this. It only dies on the U-Boot stage.
> The ddr sequence.c was somehow cropped to a point for only size and
> speed for the file comments.
> All boards or cases that even by luck passed the calibration phase on U-Boot
> do not have any issue on all stressapptest nor memtester under distro.

I guess I have been lucky then. My only real problem was that
CONFIG_TIMER_COUNTS_DOWN needs to be enabled. And it was quite an
adventure to find that (using git bisect). There are other issues,
such as watchdog kicking in if there are too many printfs(), and also
early uart access is broken.

Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Hi Ralph,

On Wed, Dec 17, 2025 at 4:18 AM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> On Thu, Dec 11, 2025 at 2:15 PM Sune Brian <briansune@gmail.com> wrote:
> >
> > > > Issue 2:
> > > > For DRAM size larger than 1GB, when w/o O.C. and using as stable
> > > > setting as possible.
> > > > Even it passed the calibration it will not cont'd boot when
> > > > sdram_gen5.c is turned on debug flag via "#define LOG_DEBUG"
> > > > However this issue is not found on 1GB nor 512MB.
> > >
> > > I was able to get access to board with 2GB, and it boots successfully.
> > > Memory calibration completes, and subsequent test with u-boot "mtest"
> > > basic memory test is also passing.
> >
> > For your 2GB case it is w/o CYCLIC and WDT right?
>
> Correct. Both my 512MB and 2GB are without CYCLIC and WDT.
>
> > For this may I ask what DDR3 speed you used? 400MHz?
>
> Yes, it is 400MHz, at least on the 512MB board.

For this let me recap the situation.
1) 400MHz on any size could run w/o CYCLIC nor WDT.
Disregarded to die configuration nor die size aka page size 1k or 2k etc.
From 512 to 2G.
2) 533MHz only properly run w/o CYCLIC nor WDT on twinDie setup
3) 500MHz is required to backoff when CYCLIC and WDT is turned off on 2k
page size die on max 2G case.

So basically speaking it is about the delay tap on the sequence.c is very
timing dependent and toucky.

>
> > For 2GB there are different die configurations 512x16 itself also come with
> > different forms. If possible can you provide the actual die part #?
>
> Unfortunately I don't have physical access (nor schematics) to check that.
>
> > The most puzzling part is this. It only dies on the U-Boot stage.
> > The ddr sequence.c was somehow cropped to a point for only size and
> > speed for the file comments.
> > All boards or cases that even by luck passed the calibration phase on U-Boot
> > do not have any issue on all stressapptest nor memtester under distro.
>
> I guess I have been lucky then. My only real problem was that
> CONFIG_TIMER_COUNTS_DOWN needs to be enabled. And it was quite an
> adventure to find that (using git bisect). There are other issues,
> such as watchdog kicking in if there are too many printfs(), and also
> early uart access is broken.
>
> Ralph

Long story short when CYCLIC/WDT is off just back off DDR speed to stable.
However it makes no sense to trade off possible system speed when it is allowed
to reach 533.333MHz.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

> > Issue 1:
> > sequencer.c if turned on debug by including this at the very top.
> > "#define LOG_DEBUG" and "#define DLEVEL 1 or 2"
> > If will stall somehow on any brand of board my side current had.
>
> I also encountered this, but it was solved by disable the watchdog, by
> toggling L4WD0 reset. After doing this, there is no problem with using
> DLEVEL 2. I even took it a step further and logged every single write
> to the DDR control registers.

Hi Ralph,

Thanks again. Quick test on your proposed method.

diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
index 3c79bb11802..904f9bc6d03 100644
--- a/drivers/ddr/altera/sdram_gen5.c
+++ b/drivers/ddr/altera/sdram_gen5.c
@@ -589,6 +589,9 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
        }
        reset_deassert_bulk(&resets);

+       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1);
+       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0);
+
        if (sdram_mmr_init_full(sdr_ctrl, 0xffffffff) != 0) {
                puts("SDRAM init failed.\n");
                goto failed;

Works and all debug_log and max level=2.

However the same behavior can be repeated when CYCLIC / WDT off.
It will fail and once CYCLIC is turned on it will pass again.

If HW level does not support the 533.333M timing from the beginning
it is a 100% fail and no possible turning back to work.
AKA you won't be able to do any timing shift to make it work.
The DDR3 chip dies are unchanged and twin dies can always run 533.333
and never stall on the calibration phase w/ CYCLIC.

So simply speaking the sequence.c somehow is so touchy on timing.
I do test the most common timing bin of the DDR3 die.
I guess there is no easy fix on this issue unless Altera do change a bit the
sequence.c syntax.

Brian

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Ralph Siemsen]

On Thu, Dec 11, 2025 at 2:51 PM Sune Brian <briansune@gmail.com> wrote:
> Hi Ralph,
>
> Thanks again. Quick test on your proposed method.
>
> diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
> index 3c79bb11802..904f9bc6d03 100644
> --- a/drivers/ddr/altera/sdram_gen5.c
> +++ b/drivers/ddr/altera/sdram_gen5.c
> @@ -589,6 +589,9 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
>         }
>         reset_deassert_bulk(&resets);
>
> +       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1);
> +       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0);
> +
>         if (sdram_mmr_init_full(sdr_ctrl, 0xffffffff) != 0) {
>                 puts("SDRAM init failed.\n");
>                 goto failed;
>
> Works and all debug_log and max level=2.

Okay, great.

> However the same behavior can be repeated when CYCLIC / WDT off.
> It will fail and once CYCLIC is turned on it will pass again.

So there would seem to be another issue related to CYCLIC, hmm...

> So simply speaking the sequence.c somehow is so touchy on timing.
> I do test the most common timing bin of the DDR3 die.
> I guess there is no easy fix on this issue unless Altera do change a bit the
> sequence.c syntax.

One other complaint about sequencer.c is its size... the compile code
takes up a major portion of the 60kB size limit for SPL.

Ralph

Re: [PATCH v4] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Sune Brian]

Hi Ralph

On Wed, Dec 17, 2025 at 4:22 AM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> On Thu, Dec 11, 2025 at 2:51 PM Sune Brian <briansune@gmail.com> wrote:
> > Hi Ralph,
> >
> > Thanks again. Quick test on your proposed method.
> >
> > diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
> > index 3c79bb11802..904f9bc6d03 100644
> > --- a/drivers/ddr/altera/sdram_gen5.c
> > +++ b/drivers/ddr/altera/sdram_gen5.c
> > @@ -589,6 +589,9 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
> >         }
> >         reset_deassert_bulk(&resets);
> >
> > +       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1);
> > +       socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0);
> > +
> >         if (sdram_mmr_init_full(sdr_ctrl, 0xffffffff) != 0) {
> >                 puts("SDRAM init failed.\n");
> >                 goto failed;
> >
> > Works and all debug_log and max level=2.
>
> Okay, great.
>
> > However the same behavior can be repeated when CYCLIC / WDT off.
> > It will fail and once CYCLIC is turned on it will pass again.
>
> So there would seem to be another issue related to CYCLIC, hmm...
>
> > So simply speaking the sequence.c somehow is so touchy on timing.
> > I do test the most common timing bin of the DDR3 die.
> > I guess there is no easy fix on this issue unless Altera do change a bit the
> > sequence.c syntax.
>
> One other complaint about sequencer.c is its size... the compile code
> takes up a major portion of the 60kB size limit for SPL.

The major concern here as I didn't fully read that file nor understand yet.
If the write is possibly ruined the data via wrong address during delay
taps trials.

Then the system is sure to stall somehow. So if the SPL phase is not
100% reliant on OCRAM only then the chance is very high to stall.
For example it uses total memory of the SDRAM lowest part i.e.
0x0 to 0x10000 etc. even this could be corrupted during the test.
However before the sequence.c could possibly reach a good delay taps,
it had been stalled by other issues and never completed.

And the most concerns from the beginning of C5 devices are they
don't even have leveling aka official don't allow fly-by yet T-branch only.

So many DDR3 standards are cropped from the beginning and even the
timing training. (I might be wrong on software level but not hardware level).

>
> Ralph

Brian