[PATCH v1] SDRAM Calibration Failed fix for GEN5 SoCFPGA

[Quentin Schulz]

Hi Brian,

On 11/24/25 3:17 PM, Sune Brian wrote:
>> Device Tree is representation of the hardware. Is the watchdog present
>> in hardware? Yes? Then status = "okay".
>>
>> Ideally, the board shouldn't fail if watchdog is enabled in DT but not
>> the driver (and vice-versa).
>>
>> Do you know what the actual issue is? Why does it fail when watchdog is
>> enabled in DT but not the driver?
> 
> Best guess watchdog timeout.
> I have no clue but this is the case.

I know some SoCs/ICs report the reset cause and you would be able to 
tell whether the reset was triggered by a watchdog or not, do you have 
such a register available maybe?

> Otherwise it cannot explain why it is always at the point of message
> check and fails.
> 

Add a substantial sleep/delay right before the last message you see and 
check if it fails after the same amount of time or not.

> If DT is enabled but not the driver then the driver is empty from first place.

My hunch is that SPL_WDT is enabled (or whatever other mechanism can be 
used to start the watchdog on this architecture/vendor) and somehow the 
watchdog is started in SPL but not in proper, in which case the watchdog 
isn't pinged. It could also be a remnant from the previous boot if this 
is a warm reboot (e.g. the IC isn't entirely/correctly reset before 
booting U-Boot).

Looking into socfpga_cyclone5_defconfig it seems that SPL_WATCHDOG is 
enabled but no driver is. Can you tell us which (failing) defconfig 
you're using (and if it supports multiple boards, which one) so we can 
check assumptions without going back and forth with you?

> AKA the watchdog never initializes proper cycling? (my assumption)

The designware watchdog cannot be stopped once started, you have to 
continuously ping it, c.f. comment at the top of the Linux kernel driver.

> If the driver enables but DT does not then it simply disables during
> probe or ops?
> (also my assumption)

If DT node is disabled, the driver won't be probed for that device, 
nothing will be done.

> 
> So simply said w/o the socfpga watchdog driver it is problematic I guess.
> So always complying with the driver and leaving DTS to do the job is the
> most stable case.
> 

That's a bandage fix. It would be better to have some idea of what's 
going on. If this is possible, bisecting between a known working and 
broken commits would hopefully return the culprit and we can start 
making educated guesses from there. I also see no defconfig in upstream 
with TARGET_SOCFPGA_GEN5

Cheers,
Quentin