mahendraguduru@yahoo.com wrote:
> IS THIS MEAN, safeMemoryBackup IS GETTING UPDATED AFTER EXECUTION OF
> LINE bzero???????

How recreatable is the failure? This sounds obvious, but what happens
if you just step through the code and watch when the memory changes? If
not, you could add some code to check your hypothesis, like if
(*(long*)safeMemoryBackup == 0x22222222) printf("What the Heck?!?!\n");
stuck at the head of the routine to check for double-execution like
Alan suggested and one before bcopy to verify what you saw.

Does the problem go away if you disable optimization in the compiler? I
have stepped through optimized MIPS C code that reorders lines pretty
radically, but it should still respect the order in which operations on
the same memory occur. It's a stretch to think that this kind of thing
could extend to calling complete macros out of order, but who knows.

    - Tim.

mahendraguduru@yahoo.com wrote:
> void sysHwInit(void)
> {

> 	/* Copying Safe Memory contents (Reboot reasons etc) into structure
> and clearing the memory*/
> 	bcopy( (char*)(SAFE_MEMORY_BASE), (char*)
> safeMemoryBackup,SAFE_MEMORY_LIMIT);
> 	bzero((char*)(SAFE_MEMORY_BASE), SAFE_MEMORY_LIMIT);

> But after execution of above code,  safeMemoryBackup contents are
> always shows Zero instead of my reboot reason.
> If I comment bzero line,
> I could see the reboot reason contents in safeMemoryBackup as expected.


Are you sure sysHwInit is not called more than once?

Alan Nishioka

Hi Alan,
Thanks for immediate repply. But I am sure that  both of them are
pointing to different memory.
as you can see from below logs, safeMemoryBackup is at 0x805182c0 and
SAFE_MEMORY_BASE was 0x81fb0000
[ODM-DEV-KERN >]safeMemoryBackup
safeMemoryBackup = 0x805182c0: value = 572662306 = 0x22222222
[ODM-DEV-KERN >]d 0x805182c0
805182c0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
805182d0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
805182e0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
805182f0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518300:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518310:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518320:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518330:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518340:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518350:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518360:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518370:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518380:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
80518390:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
805183a0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
805183b0:  2222 2222 2222 2222 2222 2222 2222 2222   *""""""""""""""""*
value = 21 = 0x15
[ODM-DEV-KERN >]

Thanks and Regards,
Mahendra

mahendraguduru@yahoo.com wrote:
> 	/* Copying Safe Memory contents (Reboot reasons etc) into structure
> and clearing the memory*/
> 	bcopy( (char*)(SAFE_MEMORY_BASE), (char*)
> safeMemoryBackup,SAFE_MEMORY_LIMIT);
> 	bzero((char*)(SAFE_MEMORY_BASE), SAFE_MEMORY_LIMIT);

> But after execution of above code,  safeMemoryBackup contents are
> always shows Zero instead of my reboot reason.
> If I comment bzero line,
> I could see the reboot reason contents in safeMemoryBackup as expected.

Are you certain safeMemoryBackup[] and SAFE_MEMORY_BASE aren't pointing
to the same memory?

This is possible if safeMemoryBackup is the first static allocation and
SAFE_MEMORY_BASE is aliasing (yes, this would be bizarre, but stranger
things have happened).

Alan Nishioka

Hi All,
We are trying to port our application from PPC405 to MIPS 4KC.
I have come across one erratic behaviour of following code snippet.

*******************************************************************************
/*Definitions for  Safe Memory Backup, reboot reasons etc */
#define SAFE_MEMORY_BASE                0x81FB0000
#define SAFE_MEMORY_LIMIT               1024
char safeMemoryBackup[SAFE_MEMORY_LIMIT];

void sysHwInit(void)
{
    int romStartedWatchdog = 1;
    unsigned int resetVal;
    unsigned int * location;
    int i;
.
.
.
 	sysBootLine = (char *)BOOT_LINE_ADRS;
  	sysExcMsg = (char *)EXC_MSG_ADRS;

	/* Copying Safe Memory contents (Reboot reasons etc) into structure
and clearing the memory*/
	bcopy( (char*)(SAFE_MEMORY_BASE), (char*)
safeMemoryBackup,SAFE_MEMORY_LIMIT);
	bzero((char*)(SAFE_MEMORY_BASE), SAFE_MEMORY_LIMIT);
************************************************************************************************************

The purpose of above bcopy function is to  write  post-mortem(which is
written in to SAFE_MEMORY_BASE while rebooting) data in to a variable
called safeMemoryBackup.

And  the bzero function is to erase the reboot reason from
SAFE_MEMORY_BASE as we already stored RebootReason contents in to a
variable called safeMemoryBackup.

But after execution of above code,  safeMemoryBackup contents are
always shows Zero instead of my reboot reason.
If I comment bzero line,
I could see the reboot reason contents in safeMemoryBackup as expected.

IS THIS MEAN, safeMemoryBackup IS GETTING UPDATED AFTER EXECUTION OF
LINE bzero???????

to confirm that, I have used following code instead of bzero routine to
erase the reboot reason.

	bcopy( (char*)(SAFE_MEMORY_BASE), (char*)
safeMemoryBackup,SAFE_MEMORY_LIMIT);
location=(unsigned int *)SAFE_MEMORY_BASE;
for(i=0;i<256;i++){
*(location)=0x22222222;
location++;
}

YES, safeMemoryBackup is getting updated with all 0x22222222.
How  this is possible?.
How can be a lower function(bzero) executes BEFORE the function that is
above  in execution order?

I have also used following cache routines before bzero, to ensure that
cache is not creating problems.
	cacheFlush (DATA_CACHE,(int *)SAFE_MEMORY_BASE, ENTIRE_CACHE);
 	cacheClear (DATA_CACHE,NULL, ENTIRE_CACHE);

Can anybody clarifies this behaviour.

Thanks in advance for your time.
Mahendra.