Warm reset issue

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?

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?

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.

Thanks.

DV

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?

Any insight?

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?

Atul

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

#if (_WINCEOSVER<600)

OALKitlPowerOff();

#else

KITLIoctl(IOCTL_KITL_POWER_CALL, &bPowerOn, sizeof(bPowerOn), NULL, 0, NULL);

#endif

// Clear context registers

OUTREG32(&pContextRestoreRegs->BOOT_CONFIG_ADDR, 0);

OUTREG32(&pContextRestoreRegs->PUBLIC_RESTORE_ADDR, 0);

OUTREG32(&pContextRestoreRegs->SECURE_SRAM_RESTORE_ADDR, 0);

OUTREG32(&pContextRestoreRegs->SDRC_MODULE_SEMAPHORE, 0);

OUTREG32(&pContextRestoreRegs->PRCM_BLOCK_OFFSET, 0);

OUTREG32(&pContextRestoreRegs->SDRC_BLOCK_OFFSET, 0);

OUTREG32(&pContextRestoreRegs->OEM_CPU_INFO_DATA_PA, 0);

OUTREG32(&pContextRestoreRegs->OEM_CPU_INFO_DATA_VA, 0);

////dv: Advisory 3.1.1.176 Accesses to DDR Stall in SDRC After a Warm-reset

//// put SDRC in Idle

CLRREG32(&pPrcmCoreCM->CM_ICLKEN1_CORE, CM_CLKEN_SDRC);

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...

OALMSG(OAL_IOCTL&&OAL_FUNC, (L"-OALIoCtlHalReboot\r\n"));

return TRUE;

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

Atul

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). 

DV

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

thanks

Atul

I do have my reasions that are too detailed to get into. I would much rather concentrate on how to implement the workaround.