software-triggered reset of MPC8541

software-triggered reset of MPC8541

[Dan Wilson]

My apologies for asking a question in this mailing list that is somewhat=
 off-topic, but this is the best list I know of for such a question:

We are trying to implement a software function to reset an 8541.  The ELDK=
 4.0 kernel includes an abort() function that does this by setting the=
 appropriate bits in DBCR0.  In our tests, this unfailingly reboots the=
 unit.  A colleague has put an identical function into a non-linux-based=
 application on which he is working, and finds that most of the time the=
 unit reboots as expected, but sometimes it just hangs.

My question is: does the linux kernel do anything special to prepare the=
 processor environment for this reboot prior to calling abort()?  The only=
 thing I could find was a call to local_irq_disable(), which does:
static inline void local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
        __asm__ __volatile__("wrteei 0": : :"memory");
#else
        unsigned long msr;
        __asm__ __volatile__("": : :"memory");
        msr =3D mfmsr();
        SET_MSR_EE(msr & ~MSR_EE);
#endif
}

As the 8541 is an E500 core, I believe it is the #ifdef CONFIG_BOOKE code=
 that is being executed.  The wrteei 0 instruction is clear enough.  What=
 does the rest of that line do (i.e., the repeated colons and the memory=
 command)?  I haven't been able to find a memory command in the ppc=
 instruction set documents that I have?

Thanks in advance for any help anyone can give to help us understand this=
 code sequence better!

Best regards,

Dan.

Re: software-triggered reset of MPC8541

[Kumar Gala]

On Mar 22, 2006, at 8:28 AM, Dan Wilson wrote:

> My apologies for asking a question in this mailing list that is  
> somewhat off-topic, but this is the best list I know of for such a  
> question:
>
> We are trying to implement a software function to reset an 8541.   
> The ELDK 4.0 kernel includes an abort() function that does this by  
> setting the appropriate bits in DBCR0.  In our tests, this  
> unfailingly reboots the unit.  A colleague has put an identical  
> function into a non-linux-based application on which he is working,  
> and finds that most of the time the unit reboots as expected, but  
> sometimes it just hangs.
>
> My question is: does the linux kernel do anything special to  
> prepare the processor environment for this reboot prior to calling  
> abort()?  The only thing I could find was a call to  
> local_irq_disable(), which does:
> static inline void local_irq_disable(void)

The problem is there is no good way of actually resetting the full  
8541 from software without additional logic on whatever system you  
have.  The abort() is a poor mans way which is only actually  
resetting the E500 core.  The rest of the system logic is left in  
whatever state it was before.

What you really need is to determine if there is some way to effect  
and board logic you may have that handles the HRESET_REQ signal.

> {
> #ifdef CONFIG_BOOKE
>         __asm__ __volatile__("wrteei 0": : :"memory");
> #else
>         unsigned long msr;
>         __asm__ __volatile__("": : :"memory");
>         msr = mfmsr();
>         SET_MSR_EE(msr & ~MSR_EE);
> #endif
> }
>
> As the 8541 is an E500 core, I believe it is the #ifdef  
> CONFIG_BOOKE code that is being executed.  The wrteei 0 instruction  
> is clear enough.  What does the rest of that line do (i.e., the  
> repeated colons and the memory command)?  I haven't been able to  
> find a memory command in the ppc instruction set documents that I  
> have?

The "memory" reference is more about GCC's assembler syntax than  
anything PPC specific.  Take a look at the GCC does for inline  
assembly to find out more.

- kumar