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 <dan...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
