[PATCH 4/5 v2] SPARC: Fatal_halt use source and exit codes

[Sebastian Huber]

On 2014-07-04 22:07, Daniel Hellstrom wrote:
>
> On 07/04/2014 04:20 PM, Joel Sherrill wrote:
>>
>>
>> On Jul 4, 2014 3:47 AM, Daniel Hellstrom <daniel at gaisler.com> wrote:
>> >
>> > On 07/03/2014 04:55 PM, Joel Sherrill wrote:
>> > > I am wondering if I don't have a vision for what this
>> > > series of patches is trying to accomplish in whole.
>> > * make exit-code propagate to debugger/hypervisor. I though this would be
>> nice for other architectures as well.
>> > * make SMP fatal exit work
>> > * instead of using BSP specific reset on LEON3, rely on RTEMS and SPARC to
>> stop execution
>> > * fix bad behaviour of SPARC fatal halt, always spinning.
>> >
>> > >
>> > > And I am hung up on not wanting BSP references in
>> > > score. So I would like an elegant solution.
>> > I understand that, however some part of me still thinks that halting is
>> very BSP specific. What makes me a bit confused is that there is just one
>> halt approach, there is no difference between reset,
>> > reboot, halt and power-down. I remember Win95 or Linux, when you type halt
>> it does not reboot or power-down the machine, since you can see the last
>> terminal shutdown message and push the power-down
>> > button yourself ;)
>> >
>> > > How does tweaking the bsp_reset() method not
>> > > address all of this? It is invoked along the _Terminate()
>> > > path already.
>> > >
>> > > As an aside, should the _Internal_errors_What_happened
>> > > structure be filled in earlier in _Terminate? How about
>> > > just after disabling interrupts?
>> > That is one of the problems I faced.
>> >   * bsp_reset() does not have any arguments of what gone wrong
>> >   * _Internal_errors_What_happened is not modified until after bsp_reset()
>> >   * _Internal_errors_What_happened can not be updated before bsp_reset() on
>> SMP since it will be written by all CPUs
>> >   * The exit codes of CPUs are different. If one CPU finds a problem,
>> signals to the others to shut down, their IPI handler will call fatal handler
>> with another exit code. Now the BSP in the fatal
>> > extions can look at the exit codes to determine which CPU requested the
>> fatal exit and handle them differently. The BSP makes sure that only one CPU
>> ends up in the
>> >
>>
>> Would it help if bsp_reset() took arguments?
>>
> No, I have implemented a bsp_fatal_handler instead with patch 5/5, that has
> both arguments. The same basic problem exists.

Yes, the bsp_reset() should just do what the name suggests, perform a reset of 
the system.

>
>> I see the problem now.
>>
> I'm not sure how to proceed. Do you want me to update the series to:
>    A. revert changes to the arguments to CPU_Fatal_halt, or
>    B. remove all arguments to CPU_Fatal_halt() in all archs, and use
> _Internal_errors_What_happened from CPU_Fatal_halt to get the currently
> required information by the archs.
>
> Then I could make SPARC BSPs totally similar by removing bsp_reset() in LEON2
> and ERC32. And remove the now unused BSP_fatal_exit introduced.

I think this change to _CPU_Fatal_halt() proposed by Daniel is right thing to 
do, then you have all information you need locally.

I would also delete this _Internal_errors_What_happened.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.