I can see in the platform.c file (6.14.1) they are reseting and re-initializing SDRC controller both on hard reset (poweron and cold boot)
and on software (GLOBAL_SW_RST) and external warm reset.
Does this not totally invalidate anything stored in DRAM? Doesn't this totally defeat the purpose of a warm boot?
What am I missing and what is the issue here?
I do notice if I remove the reinitialization under a warm boot path the OS is unstable .. even if I am reloading nk.bin.
David: I understand the concern. As it stands today did you face a problem or is it something that you saw while reviewing code.
I am using persistent registry. I need a utility to force a "Clean registry reboot" For reasons I wont go into I can't do it in the boot loader like is traditionally done.
I need to save a flag and force a (fast) warm boot.
I am wondering if the non-functional warm boot is a silicon issue or just a BSP issue or maybe I just don't understand it?
Are you using DRAM for persistent storage? Do you have an option to use NAND?
What we have tried here with 3530, is use NAND for persistent storage. Using kernel flags, NAND is mounted as root filesystem and the registry is setup to be flushed every 2 mins. On warm reboot, the registry and other data is restored using system.hv file from NAND. On cold reboot, using IOCTL, kernel checks with BSP if format needs to be done. So the NAND is formatted on cold boot when Nk.bin boots up and the previous registry changes are lost. Does this approach work for you?
Please click Verify Answer button if this response answers your question. For updated information on TI WINCE BSP, please check out the WinCE Handbook.
Yes, I realize that is how it is traditionally done and I have done it that way on other platforms. Unfortunately, this platform has no NAND.
I am still wordering if this is a silicon issue or just a BSP issue? I know the data sheet states the DRAM auto-refreshes during warm boot. So in theory the DRAM should still be intact.
Is it just the fact the BSP people could not get it working so they just decided to punt and do a SDRC reset?
to the OMAP3530 TRM, global warm reset will not reset SDRC module (see General Characteristics of Reset
Signals). However there is a silicon issue described in Advisory 220.127.116.11 Accesses to DDR Stall in SDRC After a Warm-reset.
workaround described in Advisory
18.104.22.168 is not fully implemented in the current BSP. Instead, SDRC is re-configured
every time after reset and a SDRC soft reset is done for global and external
Advisory 22.214.171.124 Accesses to DDR Stall in SDRC After
Revision(s) Affected: 3.1 and earlier
Details: In some cases, user is not able to
access DDR memory after warm-reset.
This situation occurs while the
warm-reset happens during a read access to DDR
memory. In that particular
condition, DDR memory does not respond to a corrupted read
command due to the warm reset
occurence but SDRC is waiting for read completion.
SDRC is not sensitive to the warm
reset, but the interconect is reset on the fly, thus
causing a misalignment between SDRC
logic, interconect logic, and DDR memory state.
Root cause description: A corrupted
read transaction is issued to a closed row:
(address0, bank0) instead of the
expected read access, violating protocol.
Failure signature: Once the failure
occurs and system has restarted, memory content is
not accessible. SDRC registers can
be accessed successfully, until 1st access to
memory location is performed. After
1st access to memory is done, SDRC is stuck.
Workaround(s): Steps to perform before a SW reset
is trigged, if user needs to generate a SW reset and
keep DDR memory content:
1. Set SDRC_POWER[SRFRONIDLEREQ]=1
//enable self-refresh on idle request
2. Set PRCM CM_ICLKEN1_CORE[SDRC]=0
//put SDRC in idle
3. Wait until PRCM
CM_IDLEST1_CORE[SDRC]=1 //wait until SDRC goes to idle
4. Generate SW reset
Steps to perform after warm reset
if HW warm reset is the source,
apply below steps before any accesses to SDRAM
1. Reset SMS and SDRC
SMS_SYSCONFIG.SOFTRESET=0x1, wait until
SMS_SYSSTATUS.RESETDONE = 0x1
SDRC_SYSCONFIG.SOFTRESET=0x1, wait until
SDRC_SYSSTATUS.RESETDONE = 0x1
2. Re-initialize SMS, SDRC and
memory (if SW warm reset is the source, SDRAM
can be accessed reliably with no
additional operation since user ensure above
sequence before applying the warm
Note: DDR memory content is lost upon HW
warm-reset (WDT, secure violation, …).
SDRC_POWER[SRFRONRESET] value does
Thanks for the information. This is what I was looking for.
It looks like the workaround will work for me with the GLOBAL SW RESET as I am not using the async external warn reset pin.
I was trying to implement the workaround described to get a warm reset with memory retained.
I was trying to implement in the OALIoCtlHalReboot function which does set the GLOBAL SOFTWARE RESET at the end.
I can do step 1 to enable self-refresh on idle request (which seems to be set in the startup code anyway).
But if I am executing out of DRAM (ala Windows CE or Linux) then won't step 2 kill the program in its tracks and you can never do step 3 or 4?
Is this true?
I guess you could put the workaround function in on-chip SRAM and jump to it but this seems a little messy?
Have you tried this? If so, what happens? My guess is running from SRAM is safer but the sequence you mentioned is pretty small - wouldn't you be running from ICache without hitting the memory?
I am trying to use this code from reboot.c.
I can see the **** RESET ***** message but it stalls and never recovers.
// Perform a global SW reset
OALMSG(TRUE, (L"*** RESET ***\r\n"));
// Disable KITL
KITLIoctl(IOCTL_KITL_POWER_CALL, &bPowerOn, sizeof(bPowerOn), NULL, 0, NULL);
// Clear context registers
////dv: Advisory 126.96.36.199 Accesses to DDR Stall in SDRC After a Warm-reset
//// put SDRC in Idle
while ((INREG32(&pPrcmCoreCM->CM_IDLEST1_CORE) & CM_IDLEST_ST_SDRC) != CM_IDLEST_ST_SDRC)
// Flush the cache
OEMCacheRangeFlush( NULL, 0, CACHE_SYNC_ALL );
// Do warm reset
OUTREG32(&pGlobalPrmRegs->PRM_RSTCTRL, /*RSTCTRL_RST_DPLL3|*/ RSTCTRL_RST_GS);
// Should never get to this point...
One thing that appears wrong is that you are flushing all the caches
after doing SDRC ops but before final reset - this is going to hit the
memory and stall. If at all, this should be done prior to workaround
instructions. The other thing is to make sure interrupts are disabled
when you execute this.
However, looking at the beginning of this thread I am confused as to what you are trying to accomplish? What is the product/use case that relies upon memory contents across reboot? I have never come across such a requirement or a product. Your original question "does this defeat the purpose of Warm reboot" - the answer is No
I'll try flipping the lines and see if it makes a difference.
I would say yes it does defeat the purpose of a warm boot. The way it operates now (loosing memory contents) is just a software triggered "cold boot".
There are many seneros where you would want to preserve memory contents, indeed this is how the warm reset function is described in the OMAP documentation.
Just one for example, say I would want to restart the OS without reloading from storage memory (which is painfully slow depending on the media).
Since you are building the product, you are more knowledgeable about your use case and maybe I am missing these scenarios. Here are couple of points I would like to make:
(a) diff b/w cold and warm reboot - there is more to it than just preserving memory contents. Warm reboot will be faster since portions of chip initialization can be skipped (depending upon implementation of course)
(b) from chip point of view Warm reboot as described makes sense. However from overall system point of view, especially when High level OS is involved, I am not so sure you would want to work with same memory content. Under what conditions would you undertake warm reboot? Most likely when something has gone bad/corrupted (possibly OS code itself) and one would want to start afresh. Just my opinion
I do have my reasions that are too detailed to get into. I would much rather concentrate on how to implement the workaround.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.