AM335x: DDR data preservation over a warm reset

Hi Francois,

Please see Table 8-25, and especially Note 1 below the table, in the AM335X TRM Rev. K:

"The ROM software does not utilize this feature of DRAM content preservation. Hence, the AM335x re-boots like a cold boot for warm reset as well."

Hello Biser,

Thanks for pointing that out. Are we talking about the code in ROM that boots the chips? If so this code is not doing anything with the external memory isn't it?

Yes, this is correct.

So does that change your original statement?

If we set some data in memory and launch a warm reboot. The ROM loads part of uboot to internal RAM, this code configures the memory controller then the data in the DDR should still be accessible right?

In the Table mentioned above you can also see that the PLLs enter bypass mode. This would affect the DDR clock.

In what way does it affect it? Does it prevent the memory to enter self-refresh mode?

Also see section 8.1.7.4.1.2 it says that PLL and divider are intact. I'm not sure what bypass mode is so I can't say if those two statements contradict. 

Based on figures 8-21 and 8-22 "Warm Reset Sequence" (section 8.1.7.4.1.2) of the TRM, when a warm reset is triggered EMIF is automatically put into self-refresh before the processor's internal reset signals are asserted.

It's apparently also important to program the control_emif_sdram_config register of the control module before enabling EMIF after reset to ensure the EMIF's sdram_config register is preloaded with the right contents.  (Needs to be done only once after cold reset, register is warm reset insensitive)

I also suspect you may need to set bit 31 of the control module's ddr_io_ctrl register to prevent the DDR_RSTn signal from being asserted, but I'm not sure about this one.

Matthijs van Duin said:

I also suspect you may need to set bit 31 of the control module's ddr_io_ctrl register to prevent the DDR_RSTn signal from being asserted, but I'm not sure about this one.

Yes, you should set that bit for DDR3.  It's not needed for DDR2 since DDR2 doesn't have this signal.

To avoid ambiguity, can someone confirm that with this procedure it's possible to access data in DDR memory over a warm reset?

I actually tried it and it worked but I wanted to have a confirmation before we integrate it to our platform. I though I might have been lucky.

Thanks a lot for your time.

It's probably a good idea to run some extensive tests anyway... e.g. fill RAM with a pseudo-random sequence, warm reset, then wait in the bootloader for a fair amount of time before reinitializing EMIF and verifying the entire RAM contents.  Useful test loop to run overnight or so.

Or check the signals going to RAM around reset, but that may be harder to do

Brad Griffis said:

• Push and hold the warm reset button.  Hold it a while to convince yourself that the DDR must truly be in self-refresh or you would have lost all the contents.

Mind that that can take quite a while:  asserting power-on-reset for 5 seconds resulted in zero bit errors detected in 32 MB checked.  asserting it for well over 10 seconds resulted in errors, but only 50 invalid words out of 1048576 words total.  Hence my suggestion to verify this with a script, and not with a quick glance.

Matthijs van Duin said:

Mind that that can take quite a while:  asserting power-on-reset for 5 seconds resulted in zero bit errors detected in 32 MB checked.  asserting it for well over 10 seconds resulted in errors, but only 50 invalid words out of 1048576 words total.  Hence my suggestion to verify this with a script, and not with a quick glance.

You said you asserted power-on reset. My directions were to asset the warm reset. Is that why you see corruption? 

Brad Griffis said:

You said you asserted power-on reset. My directions were to asset the warm reset. Is that why you see corruption

Yes, on purpose.  My point was that even then it takes a long time for any corruption to occur, and I needed to scan a large chunk of memory to notice a few errors*.  Visually inspecting a memory display as you suggested therefore isn't going to suffice to draw a confident conclusion that corruption didn't occur when performing a warm reset.

* I did a few more tests:  20 seconds of cold reset gave errors in 0.02% of the words scanned, half a minute of cold reset still only gave errors in 0.1% of the words scanned... 99.9% still intact.

Thanks for clarifying.  I agree that lots of testing (scripting and also bus level analysis) is a good thing!

It sounds like everything is working as expected with the warm reset (good!).